perm filename LISP.BUG[BUG,LSP]23 blob
sn#727340 filedate 1983-10-24 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00121 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00017 00002 BUG-LISP and LISP-FORUM
C00018 00003 ∂20-Aug-82 2041 George J. Carrette <GJC at MIT-MC> fixes to maclisp
C00019 00004 ∂21-Aug-82 1157 John Ruttenberg <Ruttenberg at YALE> Bug in setf and arraycall
C00022 00005 ∂21-Aug-82 1207 Jonathan Rees <Rees at YALE> (SSTATUS SYNTAX #/| ...)
C00023 00006 ∂22-Aug-82 1558 Alan Bawden <ALAN at MIT-MC> (SSTATUS SYNTAX #/| ...)
C00025 00007 ∂22-Aug-82 1647 Alan Bawden <ALAN at MIT-MC> push/defvst interaction?
C00027 00008 ∂22-Aug-82 1923 John Ruttenberg <Ruttenberg at YALE> Re: push/defvst interaction?
C00029 00009 ∂23-Aug-82 0001 George J. Carrette <GJC at MIT-MC> push/defvst interaction?
C00032 00010 ∂23-Aug-82 1409 Alan Bawden <ALAN at MIT-MC> push/defvst interaction?
C00035 00011 ∂24-Aug-82 1545 Glenn S. Burke <GSB at MIT-ML> distribution request
C00036 00012 ∂24-Aug-82 1939 Greg Skinner <EE.GDS at MIT-OZ> Lisp problem
C00038 00013 ∂24-Aug-82 1939 Barry Margolin at MIT-MULTICS Re: Lisp problem
C00040 00014 ∂27-Aug-82 1306 Glenn S. Burke <GSB at MIT-ML> (SSTATUS SYNTAX #/| ...)
C00042 00015 ∂29-Aug-82 2313 GSB@MIT-ML new format installed on MC and OZ
C00043 00016 ∂30-Aug-82 1613 JonL at PARC-MAXC Re: fixes to maclisp
C00045 00017 ∂30-Aug-82 2236 Kent M. Pitman <KMP at MIT-MC> FORMAT losing
C00047 00018 ∂31-Aug-82 2102 Glenn S. Burke <GSB at MIT-MC>
C00048 00019 ∂31-Aug-82 2107 Glenn S. Burke <GSB at MIT-MC>
C00049 00020 ∂31-Aug-82 2310 George J. Carrette <GJC at MIT-MC> hacking/assembly maclisp
C00051 00021 ∂01-Sep-82 1043 Robert P. Krajewski <RpK at MIT-ML> WITH-OPEN-FILE
C00053 00022 ∂01-Sep-82 1333 Kent M. Pitman <KMP at MIT-MC> WITH-OPEN-FILE
C00054 00023 ∂01-Sep-82 1403 Alan Bawden <ALAN at MIT-MC> WITH-OPEN-FILE
C00057 00024 ∂01-Sep-82 1958 Glenn S. Burke <GSB at MIT-MC> renamef failure
C00058 00025 ∂01-Sep-82 2045 FEINBERG at CMU-20C renamef failure
C00059 00026 ∂01-Sep-82 2227 Kent M. Pitman <KMP at MIT-MC>
C00060 00027 ∂06-Sep-82 1540 Devon S. McCullough <Devon at MIT-ML>
C00062 00028 ∂06-Sep-82 1544 Kent M. Pitman <KMP at MIT-MC>
C00063 00029 ∂06-Sep-82 1827 Robert Elton Maas <REM at MIT-MC> (LISTEN)
C00064 00030 ∂07-Sep-82 1329 Glenn S. Burke <GSB at MIT-ML> (LISTEN)
C00065 00031 ∂07-Sep-82 1737 Glenn S. Burke <GSB at MIT-MC> suspend tty code fix (tops-20 vts)
C00067 00032 ∂07-Sep-82 1738 Skef Wholey <Wholey at CMU-20C> Complr's losing lossage, of course
C00069 00033 ∂07-Sep-82 2221 Glenn S. Burke <GSB at MIT-MC> load-byte/deposit-byte miscompilation
C00070 00034 ∂09-Sep-82 0021 GSB@MIT-ML previous patch, to OPNT2
C00071 00035 ∂13-Sep-82 1324 Kent M. Pitman <KMP at MIT-MC>
C00073 00036 ∂14-Sep-82 1102 Jonathan Alan Solomon <JSol at USC-ECLC>
C00075 00037 ∂14-Sep-82 2252 Stavros M. Macrakis <MACRAK at MIT-MC> < WNA msg
C00076 00038 ∂17-Sep-82 1643 Glenn S. Burke <GSB at MIT-ML> (status ttysize) on 20X
C00077 00039 ∂17-Sep-82 1658 GSB@MIT-ML (status ttysize) bug, 20x
C00078 00040 ∂17-Sep-82 1701 GSB@MIT-ML previous patch
C00080 00041 ∂01-Oct-82 0404 Kent M. Pitman <KMP at MIT-MC> More data
C00082 00042 ∂02-Oct-82 1234 Alan Bawden <ALAN at MIT-MC> ALPHALESSP: More data
C00084 00043 ∂29-Oct-82 1519 Alan Bawden <ALAN at MIT-MC> [TONYH: forwarded] (bug-PROGRAM??????)
C00088 00044 ∂29-Oct-82 1702 JONL at PARC-MAXC Your recent note on MacLisp errors
C00101 00045 ∂31-Oct-82 1132 TONYH at MIT-AI
C00106 00046 ∂31-Oct-82 1308 George J. Carrette <GJC at MIT-MC> lossage after lossage
C00109 00047 ∂01-Nov-82 1417 David Eppstein <CSD.Kronj at SU-SCORE> SUBFORK module (LEDIT)
C00114 00048 ∂03-Nov-82 2158 JONL at PARC-MAXC 4th level indirection -- maybe you haven't yet seen this?
C00117 00049 ∂20-Nov-82 1508 GJC at MIT-MC FLAME warning: Scheme broken on OZ today.
C00121 00050 ∂20-Nov-82 1932 David C. Plummer <DCP at MIT-MC> Re: Scheme broken on OZ today.
C00129 00051 ∂21-Nov-82 2357 Martin David Connor <MARTY at MIT-MC> A minor update for Top-20 Maclisp
C00145 00052 ∂19-Dec-82 1947 JONL at PARC-MAXC Re: (\ x 0) revisited, revisited, revisited
C00147 00053 ∂19-Dec-82 2023 Glenn S. Burke <GSB at MIT-ML> Re: Re: (\ x 0) revisited, revisited, revisited
C00151 00054 ∂26-Dec-82 1917 PB e-subjob communication
C00153 00055 ∂08-Jan-83 1147 EB @ MIT-MC
C00154 00056 ∂11-Jan-83 1506 EB @ MIT-MC
C00155 00057 ∂21-Jan-83 1441 JOSHM at MIT-OZ How do I...
C00156 00058 ∂21-Jan-83 1448 JOSHM at MIT-OZ at MIT-MC How do I...
C00157 00059 ∂21-Jan-83 1850 Feinberg@CMU-CS-C How do I...
C00161 00060 ∂14-Feb-83 2041 Communications Satellite <COMSAT @ MIT-MC> Msg of Monday, 14 February 1983 20:12 EST
C00163 00061 ∂05-Apr-83 1711 Alan Bawden <ALAN @ MIT-MC> buglisphack@sail
C00164 00062 ∂05-Apr-83 1911 George J. Carrette <GJC @ MIT-MC> LOOP macro expansions into LET
C00166 00063 ∂05-Apr-83 2251 David C. Plummer <DCP@SCRC-TENEX> LOOP macro expansions
C00168 00064 ∂07-Apr-83 0125 Alan Bawden <ALAN @ MIT-MC>
C00169 00065 ∂07-Apr-83 0234 Alan Bawden <ALAN@MIT-OZ> I though we fixed this?
C00171 00066 ∂08-Apr-83 2325 Alan Bawden <ALAN @ MIT-MC> Gratuitous optimization
C00172 00067 ∂11-Apr-83 2051 Kent M. Pitman <KMP @ MIT-MC>
C00174 00068 ∂11-Apr-83 2052 Kent M. Pitman <KMP @ MIT-MC>
C00175 00069 ∂11-Apr-83 2323 Pandora B. Berman <CENT @ MIT-ML> file migrated
C00177 00070 ∂13-Apr-83 2209 Dave Touretzky at CMU-CS-A CMU MacLisp broken
C00179 00071 ∂17-Apr-83 1349 PASIEKA@MIT-OZ Pretty-Printer
C00183 00072 ∂18-Apr-83 2004 WILLIS@MIT-ML
C00185 00073 ∂18-Apr-83 2117 Kent M. Pitman <kmp at MIT-MC> WILLIS@ML's TYO gripe
C00186 00074 ∂18-Apr-83 2129 Alan Bawden <ALAN @ MIT-MC> IMAGE mode IO
C00201 00075 ∂11-May-83 0928 @USC-ECL,@MIT-MC:SMATT@MIT-OZ LOOP CONTINUE STATEMENT
C00203 00076 ∂11-May-83 0931 @USC-ECL,@MIT-MC:MOON@SCRC-TENEX LOOP CONTINUE STATEMENT
C00206 00077 ∂11-May-83 1022 @USC-ECL,@MIT-MC:SMATT@MIT-OZ LOOP CONTINUE STATEMENT
C00208 00078 ∂14-May-83 1416 @USC-ECL,@MIT-MC:KMP@MIT-OZ <LIBLSP>TTY.LSP.24 fixes bugs in <LIBLSP>TTY.KMP.20
C00212 00079 ∂14-May-83 1632 @USC-ECL:KMP@MIT-MC
C00214 00080 ∂15-May-83 0920 @USC-ECL,@MIT-MC:GJC@MIT-MC <LIBLSP>TTY.LSP.24 fixes bugs in <LIBLSP>TTY.KMP.20
C00217 00081 ∂26-May-83 2214 @USC-ECL,@MIT-MC:ALAN@MIT-OZ Yuch!
C00219 00082 ∂04-Jun-83 1636 @USC-ECL,@MIT-MC:SAZ@MIT-OZ binding 't to other things (like nil)
C00220 00083 ∂14-Jun-83 0306 @USC-ECL,@MIT-MC:CENT@MIT-ML files migrated on oz
C00223 00084 ∂14-Jun-83 2302 @USC-ECL,@MIT-MC:VaughanW@HI-MULTICS Call For Papers
C00228 00085 ∂16-Jun-83 1714 @USC-ECL:ALAN@MIT-MC New MacLisp now installed on MC.
C00241 00086 ∂29-Jun-83 1119 @USC-ECL:CFFK@MIT-MC Cursor positioning with Tops-20 lisp (in Macsyma on XX)
C00246 00087 ∂04-Jul-83 1523 @USC-ECL:JGA@MIT-MC a question of interrupts (I guess)
C00254 00088 ∂15-Jul-83 1751 @USC-ECL:ALAN@MIT-MC Mustn't call UINT0 from within a PI server
C00259 00089 ∂15-Jul-83 1927 @USC-ECL,@MIT-MC:GSB@MIT-ML .lose because of intpdl
C00260 00090 ∂16-Jul-83 2233 @USC-ECL:JPG@MIT-MC
C00264 00091 ∂19-Jul-83 1917 @USC-ECL,@MIT-MC:BEN@MIT-ML Bug in DO when compiled.
C00266 00092 ∂19-Jul-83 1917 @USC-ECL:KMP@MIT-MC
C00270 00093 ∂20-Jul-83 2228 @USC-ECL:ALAN@MIT-MC More bits.
C00282 00094 ∂05-Aug-83 1143 @USC-ECL,@MIT-MC:JUDY@MIT-OZ problem with setting the status of the random function
C00286 00095 ∂05-Aug-83 1224 @USC-ECL:KMP@MIT-MC Judy's RANDOM bug
C00288 00096 ∂06-Aug-83 0133 @USC-ECL:ALAN@MIT-MC (sstatus random (status random))
C00291 00097 ∂23-Aug-83 1147 @USC-ECL,@MIT-MC:PADGET@UTAH-20 function cells
C00298 00098 ∂23-Aug-83 1424 @USC-ECL,@MIT-MC:Deutsch.PA@PARC-MAXC Re: function cells
C00306 00099 ∂30-Aug-83 1738 @USC-ECL,@MIT-MC:Bobrow.PA@PARC-MAXC Re: function cells
C00308 00100 ∂30-Aug-83 2109 @USC-ECL:GJC@MIT-MC Function cells.
C00311 00101 ∂01-Sep-83 0534 @USC-ECL,@MIT-MC:TIM@MIT-OZ Function cells
C00315 00102 ∂01-Sep-83 1454 @USC-ECL,@MIT-MC:Bobrow.PA@PARC-MAXC Re: Function cells
C00318 00103 ∂01-Sep-83 1549 @USC-ECL,@MIT-MC:BENSON@SPA-NIMBUS Re: Function cells
C00322 00104 ∂01-Sep-83 1632 @USC-ECL,@MIT-MC:Deutsch.PA@PARC-MAXC Re: Function cells
C00325 00105 ∂01-Sep-83 1707 @USC-ECL,@MIT-MC:PADGET@UTAH-20 Re: Function cells
C00330 00106 ∂01-Sep-83 1817 @USC-ECL,@MIT-MC:Bobrow.PA@PARC-MAXC Re: Function cells
C00332 00107 ∂03-Sep-83 1232 @USC-ECL,@MIT-MC:ZVONA@MIT-OZ Function cells
C00340 00108 ∂03-Sep-83 1833 @USC-ECL,@MIT-MC:RWK@SCRC-TENEX Function cells
C00354 00109 ∂05-Sep-83 1235 @USC-ECL,@MIT-MC:Moon@SCRC-TENEX Function cells
C00356 00110 ∂05-Sep-83 1325 @USC-ECL,@MIT-MC:jkf%ucbkim@Berkeley Re: Function cells
C00359 00111 ∂05-Sep-83 1347 @USC-ECL,@MIT-MC:ZVONA@MIT-OZ Function cells
C00372 00112 ∂05-Sep-83 1625 @USC-ECL:GJC@MIT-MC Zippy the mailer, or ... are we on the net yet?
C00384 00113 ∂06-Sep-83 1759 @USC-ECL,@MIT-MC:PADGET@UTAH-20 Re: Function cells
C00389 00114 ∂06-Sep-83 1814 @USC-ECL:KMP@MIT-MC
C00391 00115 ∂06-Sep-83 1814 @USC-ECL:DCP@MIT-MC
C00393 00116 ∂17-Sep-83 1709 @USC-ECL:RIVIN@MIT-MC
C00394 00117 ∂17-Sep-83 1859 @USC-ECL,@MIT-MC:GLR@MIT-OZ SETSYNTAX and (STATUS CHTRAN) on TOPS-20
C00398 00118 ∂21-Sep-83 2258 @USC-ECL,@MIT-MC:kmp@MIT-MC TYIPEEK and SFAs -- A longstanding bug that needs fixing
C00405 00119 ∂27-Sep-83 1631 @USC-ECL,@MIT-MC:JonL.pa@PARC-MAXC Function Cells -- the history
C00417 00120 ∂27-Sep-83 1716 @USC-ECL:GJC@MIT-MC your note on Function Cells.
C00422 00121 ∂30-Sep-83 1202 @USC-ECL,@MIT-MC:GLR@MIT-OZ
C00425 ENDMK
C⊗;
BUG-LISP and LISP-FORUM
∂20-Aug-82 2041 George J. Carrette <GJC at MIT-MC> fixes to maclisp
Date: 20 August 1982 23:27-EDT
From: George J. Carrette <GJC at MIT-MC>
Subject: fixes to maclisp
To: JONL at MIT-MC
cc: BUG-LISP at MIT-MC
Can you tell us the best way to assemble a Maclisp on a tops-20
so that we can put in the various accumulated fixes in the version
on OZ? For example, the MT fix to suspend. Thanks.
∂21-Aug-82 1157 John Ruttenberg <Ruttenberg at YALE> Bug in setf and arraycall
Date: 14-Aug-82 10:55AM-EDT (Sat)
From: John Ruttenberg <Ruttenberg at YALE>
Subject: Bug in setf and arraycall
To: Bug-Lisp at MIT-MC
Seems to be a problem with push and arraycall. Here's the source file:
(defvst bug-st
(a = (*array () t 10))
)
(defmacro bug-st-ai (self index)
`(arraycall t (bug-st-a ,self) ,index))
(defun bug (self member index)
(push member (bug-st-ai self index)))
(setq b (cons-a-bug-st))
(bug b 'a 4)
(bug b 'a 4)
And here's how Maclisp takes it:
Yale Haclisp 82 (in Maclisp 2088)
> (defvst bug-st
(a = (*array () t 10))
)
;Loading DEFVST 3
;Loading EXTMAC 183
;Loading ERRCK 20
;Loading VECTOR 64
;Loading DEFVSX 85
BUG-ST
>(defmacro bug-st-ai (self index)
`(arraycall t (bug-st-a ,self) ,index))
BUG-ST-AI
>(defun bug (self member index)
(push member (bug-st-ai self index)))
BUG
>(setq b (cons-a-bug-st))
#{BUG-ST A #T-10-71712}
>(bug b 'a 4)
(A)
>(bug b 'a 4)
;G0017 UNBOUND VARIABLE
;BKPT UNBND-VRBL
> (baktrace)
BAKTRACE
+INTERNAL-UBV-BREAK← ARRAYCALL← PUSH← BUG←
It seems especially odd to me that things should blow up only after the
second call to bug.
-------
∂21-Aug-82 1207 Jonathan Rees <Rees at YALE> (SSTATUS SYNTAX #/| ...)
Date: Saturday, 14 August 1982 00:31-EDT
From: Jonathan Rees <Rees at YALE>
To: Bug-Lisp at MIT-MC
Subject: (SSTATUS SYNTAX #/| ...)
Cc: Ellis at YALE, Ruttenberg at YALE
Trying to set the syntax of | doesn't work.
(SSTATUS SYNTAX #/| 2.) ;2 is syntax of %, :, etc.
2
'|
/↑T
Vertical bars in symbols read as control-T's.
∂22-Aug-82 1558 Alan Bawden <ALAN at MIT-MC> (SSTATUS SYNTAX #/| ...)
Date: 22 August 1982 18:59-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: (SSTATUS SYNTAX #/| ...)
To: Rees at YALE
cc: BUG-LISP at MIT-MC, Ellis at YALE, Ruttenberg at YALE
Date: Saturday, 14 August 1982 00:31-EDT
From: Jonathan Rees <Rees at YALE>
(SSTATUS SYNTAX #/| 2.)
2
'|
/↑T
This is because (SSTATUS SYNTAX) doesn't know enough to set up the character
translation when it turns off a macro character. You can either do (SSTATUS
CHTRAN #/| #/|) immediately afterwords, or use (SETSYNTAX #/| 2. #/|) instead.
I started to fix this, but the code is too ugly to be believed.
∂22-Aug-82 1647 Alan Bawden <ALAN at MIT-MC> push/defvst interaction?
Date: 22 August 1982 19:29-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: push/defvst interaction?
To: BUG-LISP at MIT-MC
cc: Ruttenberg at YALE
Date: 14-Aug-82 10:55AM-EDT (Sat)
From: John Ruttenberg <Ruttenberg at YALE>
It seems especially odd to me that things should blow up only after the
second call to bug.
A smaller case of the bug:
(defvst bug-st
(a = (*array () t 10))
)
(defun bug (self member index)
(push member (arraycall t (bug-st-a self) index)))
(setq b (cons-a-bug-st))
(bug b 'a 4)
(bug b 'a 4)
After the first call to BUG it's definition has been changed to be:
(defun bug (self member index)
(push member (arraycall t <gensym> index)))
This is probably an artifact of PUSH being a fexpr (but thinking like a macro),
bug it also seems to depend heavily on the source of the array being a defvst
accessor. It doesn't happen if you are using defstruct instead. Perhaps those
responsible for defvst/push will step forward and fix?
∂22-Aug-82 1923 John Ruttenberg <Ruttenberg at YALE> Re: push/defvst interaction?
Date: 22-Aug-82 10:22PM-EDT (Sun)
From: John Ruttenberg <Ruttenberg at YALE>
Subject: Re: push/defvst interaction?
To: Alan at MIT-MC
Cc: Bug-Lisp at MIT-MC
In-Reply-To: Bawden's message of 22 August 1982 19:29-EDT
It doesn't happen if you are using defstruct instead.
We would use defstruct, except that using it into named hunks
makes it want to use some version of defvst that we don't have
here. Where are the authorative up to date sources for things
like defstruct and defvst? I'd like to know if we can get
this fix and others like it.
Also note that I don't seem to be able to compile the bug infested
code. (Same problem - some unbound gensym in the push expression).
-------
∂23-Aug-82 0001 George J. Carrette <GJC at MIT-MC> push/defvst interaction?
Date: 23 August 1982 02:45-EDT
From: George J. Carrette <GJC at MIT-MC>
Subject: push/defvst interaction?
To: Ruttenberg at YALE
cc: ALAN at MIT-MC, BUG-LISP at MIT-MC
As a bit of honest practical advice, I would concur with ALAN in
suggesting that you use DEFSTRUCT in preference to DEFVST.
The story goes like this: DEFVST was supposed to be part of
a package of code which was "NILCOM," common to both NIL and Maclisp,
and presumably to be part of "common-lisp." As it turned out though,
the implementation of all of that "NILCOM" code was too tentative
and kludgy to be worth bringing up in actual VAX NIL, so instead
code like Defstruct (which is de-facto common-lisp)
was brought up. So you see, there can be little
incentive here (at MIT) to support/fix-bugs in code such as DEFVST.
On the other hand, it is quite easy for me to make available to
you an option to defstruct called "EXTEND" which does the same
job as "DEFVST" except that the interface is a lot cleaner,
and it actually works! (It is what RLB and I used last summer to
cross-compile NIL from the pdp-10 to the VAX). You can get it
by FTPing "GJC;SFIX FASL" from the MIT-MC machine. Source is in
"GJC;SFIX >" on MIT-MC.
To answer your question about source code: The most up-to-date
versions of things are on the LIBDOC, LSPSRC, and NILCOM directories
on MIT-MC. The *best* solution seems to be to keep a winning
Maclisp environment working on MIT-OZ, and let people FTP
stuff from there.
-gjc
∂23-Aug-82 1409 Alan Bawden <ALAN at MIT-MC> push/defvst interaction?
Date: 23 August 1982 17:03-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: push/defvst interaction?
To: Ruttenberg at YALE
cc: BUG-LISP at MIT-MC
Date: 22-Aug-82 10:22PM-EDT (Sun)
From: John Ruttenberg <Ruttenberg at YALE>
It doesn't happen if you are using defstruct instead.
We would use defstruct, except that using it into named hunks
makes it want to use some version of defvst that we don't have
here. Where are the authorative up to date sources for things
like defstruct and defvst? I'd like to know if we can get
this fix and others like it.
I heve never released a version of defstruct that had anything whatsoever to do
with ANY of the out-of-core (autoloading) MacLisp libraries. There is a
feature that made defstruct a front end for defvst which I have never released
to anyone, but that wouldn't do you any good anyway. Can you send me an
example of a defstruct that tries to load ANYTHING? Up-to-date defstruct FASL
can be found on LISP;STRUCT FASL.
Also note that I don't seem to be able to compile the bug infested
code. (Same problem - some unbound gensym in the push expression).
I'm not surprised that you can't compile it either.
∂24-Aug-82 1545 Glenn S. Burke <GSB at MIT-ML> distribution request
Date: 24 August 1982 18:40-EDT
From: Glenn S. Burke <GSB at MIT-ML>
Subject: distribution request
To: TY at MIT-ML
cc: BUG-LISP at MIT-ML
tar@MIT-ML (Sent by ←←←036@MIT-ML) 08/24/82 14:48:02 Re: Phone message
Steve Cadrak called.
Academic Computing Center
University of Vermont
Burlington, VT 05405
He would like to obtain the latest MACLISP. (He has version 2009)
TOPS-20 version 5.
(802) 656-3910
∂24-Aug-82 1939 Greg Skinner <EE.GDS at MIT-OZ> Lisp problem
Date: 24 Aug 1982 2050-EDT
From: Greg Skinner <EE.GDS at MIT-OZ>
Subject: Lisp problem
To: bug-lisp at MIT-OZ
Subject: LISP problem
Is this a bug or just a feature? (especially (gcd 15 5)
evaluating to 1, while the others seem to evaluate correctly).
Plus, is there any way that LISP can be set so that base 10
numbers are echoed as such? (re 8 = 10 and 10 = 10)
[PHOTO: Recording initiated Tue 24-Aug-82 8:37PM]
TOPS-20 Command processor 4(661)-2
@lisp
LISP 2129
Alloc? n
*
(gcd 15 5)
1
(gcd 30 10)
10
(gcd 8 4)
4
(gcd 60 30)
30
(gcd 50 5)
5
(quotient 50 4)
12
50
50
(quit)
@pop
[PHOTO: Recording terminated Tue 24-Aug-82 8:38PM]
-------
∂24-Aug-82 1939 Barry Margolin at MIT-MULTICS Re: Lisp problem
Date: 24 August 1982 20:56 edt
From: Barry Margolin at MIT-MULTICS
Subject: Re: Lisp problem
Sender: Margolin.Multics at MIT-MULTICS
To: Greg Skinner <EE.GDS at MIT-OZ>
cc: bug-lisp at MIT-OZ
In-Reply-To: Message of 24 August 1982 20:50 edt from Greg Skinner
There were no bugs displayed in that session. By default, Maclisp is in
base 8, and 15(8) = 13(10) (where the notation xx(n) means the numeral
xx in base n), and the GCD of 5(10) and 13(10) is indeed 1. The
variables that control the base that numbers are input and output in are
"base", which is the base that numbers are output in, and "ibase", which
controls the input base. Associated with these is the variable
"*nopoint", which if set to T causes the decimal point that normally
follows decimal numbers on output to be suppressed. Note that any
fixnum that has a trailing decimal point (as in 100.) is also read in in
decimal, regardless of the setting of ibase, so to initially set the
base variables you should say:
(setq base 10.)
(setq ibase 10.)
∂27-Aug-82 1306 Glenn S. Burke <GSB at MIT-ML> (SSTATUS SYNTAX #/| ...)
Date: 27 August 1982 15:51-EDT
From: Glenn S. Burke <GSB at MIT-ML>
Subject: (SSTATUS SYNTAX #/| ...)
To: Rees at YALE
cc: Ellis at YALE, Ruttenberg at YALE, BUG-Lisp at MIT-MC
I believe that SETSYNTAX is what you want here; it assumes that the
choices (bits only, MACRO, SPLICING) are mutually exclusive. (sstatus
syntax ...) only hacks the syntax bits. In obscure applications this
is actually useful (the fact that it doesn't clobber the macro/chtran
entry, that is), because you can do strange and perverse things with
something like "." so that it is still decimal point but also acts
like a special-token (implemented as a reader macro). (I've done this.
It almost works.)
∂29-Aug-82 2313 GSB@MIT-ML new format installed on MC and OZ
From: GSB@MIT-ML
Date: 08/30/82 01:34:11
Subject: new format installed on MC and OZ
GSB@MIT-ML 08/30/82 01:34:11 Re: new format installed on MC and OZ
To: (BUG LISP) at MIT-ML
format 827 has been put on MC and OZ. the file types involved are
FASL, BRACK, FLOAT, NUM, and UMACS. This fixes a fencepost bugs
in ~$ and a misfeature in operator definition via define-format-op,
and maybe some other things which i have since forgotten.
∂30-Aug-82 1613 JonL at PARC-MAXC Re: fixes to maclisp
Date: 30 Aug 1982 16:10 PDT
From: JonL at PARC-MAXC
Subject: Re: fixes to maclisp
In-reply-to: GJC's message of 20 August 1982 23:27-EDT
To: George J. Carrette <GJC at MIT-MC>
cc: JONL at MIT-MC, BUG-LISP at MIT-MC
I've just returned from two weeks travelling (LispConference, AAAI, MIT
visit etc) and I didn't see you at MIT -- are you still there?
There used to be a .CTL file on MIT-XX, PS:<MACLISP>ASSLIS.CTL, which
you could just SUBMIT and it would doo all the rest. It would leave
an *uninitialized* result on SS:<MACLISP>BBLISP.EXE.<nnnn> and also
do an initialization phase leaving PS:<MACLISP>XLISP.EXE.<nnnn> and
PS:<MACLISP>LISP.SYMBOLS.<nnnn>. You then rename XLISP to LISP after
certifying that things are winning. The value of the uninitialized
file is that it's hard to patch the LISP.EXE file with the existing NDDT since
it involves changing file page accessibilities (read-only etc).
∂30-Aug-82 2236 Kent M. Pitman <KMP at MIT-MC> FORMAT losing
Date: 31 August 1982 01:15-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Sender: VP at MIT-MC
Subject: FORMAT losing
To: GSB at MIT-MC
cc: BUG-LISP at MIT-MC
In Maclisp 2122, Format 827. on MIT-MC:
Ignoring the rough points in what these actually ask FORMAT to do ('cuz
there are a few conceptual bugs), these functions do not behave in ways
even remotely resembling what the LispM does with them. For example, the
LispM does not err, pdl-overflow, or complain of missing ~]'s. Simple
tests like (f nil), (f '(a)), (f '(a b)), (f '(a b c)) and likewise for g
should give you a feel for what I'm talking about. G'luck.
(defun f (x)
(lexpr-funcall #'format t "~#[nothing~;~S~;~S and ~S~
~:;~@{~<~% ~1,50:;~#[~1; and~] ~S~>~↑,~}~]" x))
(defun g (x)
(format t "~%;; ~{~<~%;; ~1,50:;~#[~1; and~] ~S~>~↑,~}.~%" x))
-kmp
∂31-Aug-82 2102 Glenn S. Burke <GSB at MIT-MC>
Date: 31 August 1982 23:57-EDT
From: Glenn S. Burke <GSB at MIT-MC>
To: BUG-LISP at MIT-MC
on OZ,
∂31-Aug-82 2107 Glenn S. Burke <GSB at MIT-MC>
Date: 1 September 1982 00:00-EDT
From: Glenn S. Burke <GSB at MIT-MC>
To: BUG-LISP at MIT-MC
on oz, an LH/| page disappears when the job is suspended and restarted.
One gets a memory protection violation...
∂31-Aug-82 2310 George J. Carrette <GJC at MIT-MC> hacking/assembly maclisp
Date: 1 September 1982 02:04-EDT
From: George J. Carrette <GJC at MIT-MC>
Subject: hacking/assembly maclisp
To: JONL at MIT-MC
cc: BUG-LISP at MIT-MC
Thanks for the info, now, I wonder if I have *read* access to the
Maclisp directory on XX? sigh... it is a wonder anything gets done
at MIT inside LCS. Yes, I expected to be at the lisp conference,
but when the time came to leave it seemed more fun to stay at
ATARI and hack up some demo's in NIL on their brand-new 780.
I heard that some of the graphics in TRON were done in Maclisp
on a Foonly (by the way). Remember that bug note/question about
extened objects and arithmetic some months ago? I think it
was from the same guy, Craig Renolds?
Anyway, thats the state of things, I'll be at ATARI again in a little
while and I'll give you a call in Palo Alto, want to see some
3-D graphics in NIL controlled via the flavor system?
[No, I didn't implement a number-compiler for NIL yet, the crunching
stuff is written in (sigh) "C" which gets interfaced to NIL in the
obvious way.]
-gjc
∂01-Sep-82 1043 Robert P. Krajewski <RpK at MIT-ML> WITH-OPEN-FILE
Date: 1 September 1982 13:40-EDT
From: Robert P. Krajewski <RpK at MIT-ML>
Subject: WITH-OPEN-FILE
To: BUG-Lisp at MIT-MC
cc: RpK at MIT-OZ
Does WITH-OPEN-FILE exist in MacLisp ? It would be a very nice
thing to have. I'd define a robust version of it, but I don't
know how MacLisp does UNWIND-PROTECTs and such. (If you take
out the clean-up code, it's very simple.)
This may be a stupid question, but why don't the objects
returned by OPEN accept messages like :TYO, :TYI, :STRING-OUT,
:LINE-OUT, :TRUENAME, and so on ? All they seem to accept are
very general messages that would be handled by the Lisp Machine
SI:VANILLA-FLAVOR -- :PRINT-SELF and others.
``Bob''
∂01-Sep-82 1333 Kent M. Pitman <KMP at MIT-MC> WITH-OPEN-FILE
Date: 1 September 1982 16:27-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Subject: WITH-OPEN-FILE
To: RPK at MIT-MC
cc: BUG-LISP at MIT-MC
There is a package on LIBLSP called IOTA which does what you want. I'm working
on a library of macros and functions to help people trying to hack Lisp
Machine compatibility. Among things in that library will be WITH-OPEN-FILE.
For now, though, IOTA is the thing to use. It's used heavily in lots of Maclisp
systems and works fine. Documentation is in LIBDOC;IOTA >
-kmp
∂01-Sep-82 1403 Alan Bawden <ALAN at MIT-MC> WITH-OPEN-FILE
Date: 1 September 1982 16:56-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: WITH-OPEN-FILE
To: RpK at MIT-ML
cc: BUG-LISP at MIT-MC, RpK at MIT-OZ
Date: 1 September 1982 13:40-EDT
From: Robert P. Krajewski <RpK at MIT-ML>
Does WITH-OPEN-FILE exist in MacLisp ? It would be a very nice
thing to have. I'd define a robust version of it, but I don't
know how MacLisp does UNWIND-PROTECTs and such. (If you take
out the clean-up code, it's very simple.)
MacLisp does UNWIND-PROTECT by having an UNWIND-PROTECT special form just like
the LispMachine's. There is no built-in WITH-OPEN-FILE macro, but clearly you
can write your own using UNWIND-PROTECT, or wait until KMP writes one (he'll
think of some screws you never dreamed of I'll bet) or you can convert your
code to using IOTA.
This may be a stupid question, but why don't the objects
returned by OPEN accept messages like :TYO, :TYI, :STRING-OUT,
:LINE-OUT, :TRUENAME, and so on ? All they seem to accept are
very general messages that would be handled by the Lisp Machine
SI:VANILLA-FLAVOR -- :PRINT-SELF and others.
I don't understand this question in the least. The objects returned by OPEN
don't except ANY messages. They are not message recieving objects. They do
have a printed representation, but that isn't accomplished by sending any
messages. You don't do I/O by sending them messages, but by calling functions
like PRINC and TYO and passing them the "file object" as an argument.
∂01-Sep-82 1958 Glenn S. Burke <GSB at MIT-MC> renamef failure
Date: 1 September 1982 22:52-EDT
From: Glenn S. Burke <GSB at MIT-MC>
Subject: renamef failure
To: BUG-LISP at MIT-MC
the IOJRST at RENAM5+6 should be a JFCL. If the RNAMF fails then the
file has been closed but the jfn not released. The IOJRST after the
failing CLOSF will clobber the first error message (and probably not
allow the error to return because iojrst stack hacks probably aren't
additive). I have changed this in the source, someone patch it on
a 20?
∂01-Sep-82 2045 FEINBERG at CMU-20C renamef failure
Date: 1 September 1982 23:36-EDT (Wednesday)
From: FEINBERG at CMU-20C
To: Glenn S. Burke <GSB at MIT-MC>
Cc: BUG-LISP at MIT-MC
Subject: renamef failure
Howdy!
It is patched on OZ.
--Chiron
∂01-Sep-82 2227 Kent M. Pitman <KMP at MIT-MC>
Date: 2 September 1982 01:19-EDT
From: Kent M. Pitman <KMP at MIT-MC>
To: RPK at MIT-MC
cc: BUG-LISP at MIT-MC
I put a package on LIBLSP; (and <LIBLSP> on OZ) called LISPM. Please play
with this and tell me if it gives you any troubles. If no one reports any
bugs in a week or two, I'll announce it to INFO-MACLISP. The file defines
compatibility definitions for DEFSUBST, DOLIST, DOTIMES, MEXP, WITH-OPEN-FILE
and WITH-OPEN-STREAM. Documentation is in LIBDOC;LISPM > and in
OZ:PS:<LIBLSP>LISPM.LSP
-kmp
∂06-Sep-82 1540 Devon S. McCullough <Devon at MIT-ML>
Date: 6 September 1982 18:39-EDT
From: Devon S. McCullough <Devon at MIT-ML>
To: BUG-lisp at MIT-OZ
In lisp in Remote-File 14.0, LMFILE-Remote 18.0, MIT-Specific 10.0,
System 87.19, Experimental ZMail 46.3, microcode 164, No, devon,
on Lisp Machine One:
In the blue manual on page 158, 11.1 describing closures, it says
The form (closure var-list function), where var-list is a list of...
...
the value cells of the symbols. Then function is applied to the ARGUMENT. (This...
in the next-to last paragraph on the page. ARGUMENT should be plural, or I'm mixed up!
∂06-Sep-82 1544 Kent M. Pitman <KMP at MIT-MC>
Date: 6 September 1982 18:38-EDT
From: Kent M. Pitman <KMP at MIT-MC>
To: BUG-LISP at MIT-MC
I forwarded DEVON's bug report to BUG-LISPM where it should have gone.
∂06-Sep-82 1827 Robert Elton Maas <REM at MIT-MC> (LISTEN)
Date: 6 September 1982 21:20-EDT
From: Robert Elton Maas <REM at MIT-MC>
Subject: (LISTEN)
To: BUG-LISP at MIT-MC
Why does (LISTEN) take about 100 miliseconds (0.1 second) to execute?
This seems to be a very long time.
∂07-Sep-82 1329 Glenn S. Burke <GSB at MIT-ML> (LISTEN)
Date: 7 September 1982 16:07-EDT
From: Glenn S. Burke <GSB at MIT-ML>
Subject: (LISTEN)
To: BUG-LISP at MIT-MC
i replied to REM
∂07-Sep-82 1737 Glenn S. Burke <GSB at MIT-MC> suspend tty code fix (tops-20 vts)
Date: 7 September 1982 18:46-EDT
From: Glenn S. Burke <GSB at MIT-MC>
Subject: suspend tty code fix (tops-20 vts)
To: BUG-LISP at MIT-MC
cc: mt at MIT-OZ
According to MT, the problem is that Lisp is setting a whole
word with stmod rather than only the left half as it should;
this can be fixed by making it do RTMOD, and then HLL 2,TI.ST6
rather than the MOVE it now does, at OPNT2+twentysome.
This has been fixed in the source, and patched into the BBLISP on OZ.
We made a .EXE, but did not install it on <SUBSYS> yet (it was in use).
∂07-Sep-82 1738 Skef Wholey <Wholey at CMU-20C> Complr's losing lossage, of course
Date: Tuesday, 7 September 1982 20:14-EDT
From: Skef Wholey <Wholey at CMU-20C>
To: Bug-Complr at MIT-MC
Subject: Complr's losing lossage, of course
Let's see what complr does with the following code:
-----
;;; -*- Lisp -*-
;;;
;;; COMPLR LOSSAGE!!!
;;;
(defconst const-1 0)
(defconst const-2 3)
(defmacro combine-somehow (a b)
`(deposit-byte ,b 28 4 ,a))
(defun fleep ()
(print (combine-somehow const-1 const-2))
(print (combine-somehow const-2 const-1))
(print (combine-somehow 0 3))
(print (combine-somehow 3 0)))
-----
When compiled, (fleep) prints the following:
3
0
3
805306368
Seems a little bogus, huh?
[I realize that no one does much MacLisp maintainence these days, but I just
needed someone to flame at...]
--Skef
∂07-Sep-82 2221 Glenn S. Burke <GSB at MIT-MC> load-byte/deposit-byte miscompilation
Date: 8 September 1982 00:55-EDT
From: Glenn S. Burke <GSB at MIT-MC>
Subject: load-byte/deposit-byte miscompilation
To: Wholey at CMU-20C
cc: BUG-COMPLR at MIT-MC
I have identified the problem in the source, but not tested or
installed the fixes yet (get to it tomorrow). There were a
couple things wrong. Stay tuned...
∂09-Sep-82 0021 GSB@MIT-ML previous patch, to OPNT2
From: GSB@MIT-ML
Date: 09/09/82 03:20:05
Subject: previous patch, to OPNT2
GSB@MIT-ML 09/09/82 03:20:05 Re: previous patch, to OPNT2
To: (BUG LISP) at MIT-ML
is incorrect. I'll publicize the correction when i stop being shafted
by losing hardware, and when i go over it with a Travers
∂13-Sep-82 1324 Kent M. Pitman <KMP at MIT-MC>
Date: 13 September 1982 16:18-EDT
From: Kent M. Pitman <KMP at MIT-MC>
To: ALAN at MIT-MC
cc: BUG-LISP at MIT-MC, bug-oz at MIT-OZ, gsb at MIT-ML
It's sort of a bug in Autokeep (or maybe in Twenex) that you can't set
the Autokeep bit for an entire cluster of files and have it apply to new
versions when written. I think what happened is that when Glenn wrote the
patch the other night to fix SUSPEND lossage, he didn't set the autokeep
bit back on. This was not so much an issue of OZ policy or anything silly
like that as just an easy slip to have happen. This is yet another good
reason why <SUBSYS>MACLISP should probably be an unchanging .EXE file
which does nothing more than reload some other file (such as <MACLISP>'s
MACLISP.EXE). I think this is what is done on EE and I think the reasons
are similar. In any case, sorry for your lost work. It was not intended
that it shouldn't be kept.
-kmp
∂14-Sep-82 1102 Jonathan Alan Solomon <JSol at USC-ECLC>
Date: Tuesday, 14 September 1982 10:52-PDT
From: Jonathan Alan Solomon <JSol at USC-ECLC>
To: David C. Plummer <DCP at MIT-MC>
Cc: ALAN at MIT-MC, BUG-LISP at MIT-MC, bug-oz at MIT-OZ, gsb at MIT-ML,
KMP at MIT-MC
Address: 3737 South Hoover Street Room PHE 204
Los Angeles, California 90089-0273
Phone: (213) 202-1793
Yes for V5, If you save a <SYSTEM>EXEC.EXE properly with this switch
set it will remain set for everyone. Individual users who want to
change it can simply unset it in their COMAND.CMD files.
In my exec there already exists a command to override the file
setting. People seem to be doing SET FILE (no) EPHEMERAL and (no)
AUTOKEEP at random and whenever they feel like it. If you INSTALL LISP
SYS:LISP.EXE AUTOKEEP NO CONFIRM you will *always* get a Kept lisp no
matter what anyone does to the file (this is in my exec under v4).
--JSol
∂14-Sep-82 2252 Stavros M. Macrakis <MACRAK at MIT-MC> < WNA msg
Date: 15 September 1982 01:50-EDT
From: Stavros M. Macrakis <MACRAK at MIT-MC>
Subject: < WNA msg
To: BUG-LISP at MIT-MC
(< 4.5 3)
;4.5 fixnum cant compare to flonum
args=4.5
(return '(4))
...still unhappy...
(return '(3.4))
...happy...
∂17-Sep-82 1643 Glenn S. Burke <GSB at MIT-ML> (status ttysize) on 20X
Date: 17 September 1982 19:44-EDT
From: Glenn S. Burke <GSB at MIT-ML>
Subject: (status ttysize) on 20X
To: ALAN at MIT-MC
cc: BUG-lisp at MIT-MC
Fixed in the source, STATUS 259 (hohoho). The sign bit is used for
(status terpri) on a per-file basis, and things like LINEL and this
code have to be careful to use magnitude only. I will patch this in
on OZ and XX shortly.
(sstatus terpri t [file]) sets this; it is probably being done by something
you load up.
∂17-Sep-82 1658 GSB@MIT-ML (status ttysize) bug, 20x
From: GSB@MIT-ML
Date: 09/17/82 19:46:34
Subject: (status ttysize) bug, 20x
GSB@MIT-ML 09/17/82 19:46:34 Re: (status ttysize) bug, 20x
To: (BUG LISP) at MIT-ML
i should have said, STTYS1+1 should use MOVM rather than MOVE.
∂17-Sep-82 1701 GSB@MIT-ML previous patch
From: GSB@MIT-ML
Date: 09/17/82 19:57:35
Subject: previous patch
GSB@MIT-ML 09/17/82 19:57:35 Re: previous patch
To: (BUG LISP) at MIT-ML
well it's patched in the bblisp on oz.
The scheme dump shares with lisp on the wrong dir so i can't replace
the <maclisp> copy, and XX is wedged in such a way that i can only
get in via telnet which seems to interpret <cr> as <lf> in nddt.
∂01-Oct-82 0404 Kent M. Pitman <KMP at MIT-MC> More data
Date: 1 October 1982 07:01-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Subject: More data
To: BUG-LISP at MIT-MC
cc: JPG at MIT-MC
Well, my feeling is that people shouldn't rely on the exact truth value
which comes back from a true/false predicate. Sad that it ws documented
like that.
By the way, here's some more data. There seems to be a pattern:
Arg1 Arg2 Return Value
A AB T
AB ABC T
ABC ABCD T
ABCD ABCDE T
ABCDE ABCDEF LESSP
ABCDEF ABCDEFG T
ABCDEFG ABCDEFGH T
ABCDEFGH ABCDEFGHI T
ABCDEFGHI ABCDEFGHIJ T
ABCDEFGHIJ ABCDEFGHIJK LESSP
ABCDE ABCDEFG LESSP
Looks like when the characters match exactly up to the length of the first
symbol and the second symbol's pname continues on, the symbol LESSP is
returned. Pretty odd.
∂02-Oct-82 1234 Alan Bawden <ALAN at MIT-MC> ALPHALESSP: More data
Date: 2 October 1982 15:31-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: ALPHALESSP: More data
To: BUG-LISP at MIT-MC, JPG at MIT-MC, KMP at MIT-MC
Date: 1 October 1982 07:01-EDT
From: Kent M. Pitman <KMP>
Looks like when the characters match exactly up to the length of the first
symbol and the second symbol's pname continues on, the symbol LESSP is
returned. Pretty odd.
The fix is to patch the MOVEI D,QLESSP at ALPHAL to be MOVE D,VT.ITY
It only seems to matter whether D contains NIL or non-NIL except that the
contents of D get returned in the special case that JPG discovered.
∂29-Oct-82 1519 Alan Bawden <ALAN at MIT-MC> [TONYH: forwarded] (bug-PROGRAM??????)
Date: 29 October 1982 18:17-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: [TONYH: forwarded] (bug-PROGRAM??????)
To: BUG-LISP at MIT-MC
Date: 29 October 1982 17:56-EDT
From: TONYH at MIT-AI
To: BUG-PROGRAM at MIT-AI
I have three little problems which defy all of the info we have here.
If anyone can offer any help or suggestions we'd be very grateful.:
(1) Macros which are compiled in one file cannot be called from
another file if the latter is also compiled. The error message is
MACRO NOT PERMITTED IN UUO CALL. We think it must be something to
do with the declarations made at the tops of files for the compiler's
sake, but we have no information about them, and all our guesses based on
MacLisp source files have failed;
(2) We have tried to make the tilde a special readmacro. The idea is that special
comments within a file (they're quoted strings) should be prefaced by the tilde,
and that when the file is loaded the readmacro will place these comments
into a HELP system. The file containing the readmacro definition is
compiled, and the idea works well as long as the files subsequently loaded
(those with the tilde-ised comments in) are not compiled. The readmacro won't
work on FASL files , including its own file.
Also, does anyone happen to know how to stop typed-in characters from
being echoed back to the terminal? I'm trying to build alittle keypad-
driven editor, but my keypad (VT52) sends three characters at once,
which I'd rather not see!
Oh - I've just remembered another one. Our MacLisp occasionally has fits
of GC←DAEMON errors involving STRING-COMPRESS-SPACE, and frankly none of
us can understand the source code which might tell us why...
Many thanks in advance to anyone who can help, from the very heart of
quaint little old England.
Tony.
∂29-Oct-82 1702 JONL at PARC-MAXC Your recent note on MacLisp errors
Date: 29 OCT 1982 1700-PDT
From: JONL at PARC-MAXC
Subject: Your recent note on MacLisp errors
To: TONYH at MIT-AI
cc: BUG-LISP at MIT-MC
Your questions (1) and (2) arise from misunderstanding how and
when macros are applied (both readmacros and interpreter/compiler
macros).
1) Macros are never "called" in the sense that we think of calling
a funciton -- they are "expanded" by the interpreter and compiler,
but of course if they are not available to the compiler when compiling
some file, then no expansion can be done, and the compiler will defaultly
assume that the unknown name stands for a function call (rather than for
some macro to be expanded).
2) when READing a file, the s-expressions are stored as ascii text, and
the readmacro characters are invoked when such character is encountered
by the READer; FASL files, on the contrary, store either the
compiled versions of programs, or a special internal-format for other
s-exressions. Perhaps a reasonable approach is for the tilde macro
merely to append to some global list, which is then output near the end of
your file. Thus both ascii files being READ and compile dFASL files would
have a consistent representation of what is wanted in the HELP system (namely,
the list of goodies which was produced by READing the ffile in the first place).
As for deletion of the echo, it will depend on what kind of system you are using
TOPS10 or TOPS20. If the latter, you can turn of echoing by an appropriate STATUS
call which sets the bits in the TOPS20 echocontrol words; There may be some explanation
of this (i.e., the extended STATUS calls for TOPS20) in the note which I used to
attach to the distributed MacLisp tapes.
As for the GCDAEMON reported errors, it sounds like you have a copy of the STRING
package from early to mid 1980. Many bugs in it were fixed in late 1980 and
very early 1981, so these problems should go away if you can get the current
distribution (which was supposed to have taken place just as I was leaving MIT
in mid March of this year.)
More hints on problems (1) and (2)
Thus usual procedure for using "compiled" macros is to seperate them out
into a file by themselves, and have them loaded into the compiler each time
you compile some file which might use some of them. Admittedly this is not quite
as nice as defining the macros where they might "naturally" occur, but . . .
Suppose you have your tilede macro collect some data into TILDELIST. Then at the
end of the file you could put a form
(SETQ DATASTUFF '#.TILDELIST)
this wouold be one way of insureing that DATASTUFF would have the save value after
loading the FASL file as when loading thee source file.
∂31-Oct-82 1132 TONYH at MIT-AI
Date: 31 October 1982 13:05-EDT
From: TONYH at MIT-AI
To: BUG-LISP at MIT-AI
Dear JONL -
Thank you very much for your help. Unfotunatley, in trying to make
use of it ZI seem to have made things worse, to such an extent that the system
itself pleaded with me to call you again. I'd better show you what I'm
doing - you'll probably see at a glance what horrors I'm perpetrating on your
long-suffering MacLisp:
(declare (SETQ DEFMACRO-FOR-COMPILING 'T DEFMACRO-DISPLACE-CALL 'T)
(special helplist))
;;; During loading, the tilde (~) readmacro allows the special comments
;;; in this file to be stored for later access by the APROPOS function.
;;; On the property-list of 'HELP, under the property 'COMMENTS, will
;;; be found a list of the comments, each element being a dotted pair
;;; of the unquoted part of the comment and the quoted part.
(eval-when (compile load)
(and (status feature COMPLR)
(own-symbol DEFREADMACRO /~-readmacro))) ;superstition...
(eval-when (eval load compile)
(setq helplist nil)
(defmacro defreadmacro (char &rest body)
(let ((macro-name (symbolconc char '-readmacro)))
(setsyntax char 'macro macro-name)
`(defun ,macro-name () ,.body)))
(defreadmacro /~
(let* ((/↑q t) (comment `(,(read) ,[atsign](read))))
(push comment helplist)
t)))
[atsign] intended to represent the symbol on this machine!
Then follows the comment itself:
~MSG "Simple formatter..."
...and the function it is supposed to describe - also a macro. Then,
a line I added in the belief that it was the kind of thing you were advising:
(putprop 'help '#.helplist 'comments)
That's the end of the file. I then tried to compile it:
;BKPT DATA So I did:
$p
(COMMENT **ERROR** #75526 Unrecognizable datum ←← Collecatoms in function FOO)
; %%%%%%%%%%%%%%%%%%%%COMPILER ERRO(R - CALL JONL%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
;BKPT BARF
Ugh, what have I done? Sorry to bother you with this again so soon. I would
have flogged on with it on my own except for what the machine said just there.
As to your other valuable help - yes, I had just about reached the same
conclusion regarding how to re-use "compiled" macros. I just hoped,
(we are riddled with superstition here) that there might be a clever way
around the problem. We seem to have the May '82 version of STRING, but
I'll check that the dates are right. And Lord alone knows what happened
to any notes you included with the source tapes - such things go
through many administrative hands before reaching poor hackers like us!
Thank you again, anyway.
Tony.
∂31-Oct-82 1308 George J. Carrette <GJC at MIT-MC> lossage after lossage
Date: 31 October 1982 16:04-EST
From: George J. Carrette <GJC at MIT-MC>
Subject: lossage after lossage
To: TONYH at MIT-AI
cc: BUG-LISP at MIT-MC
It doesn't help to be superstitious about Maclisp. In fact, it helps a lot
to keep things as simple as possible, not using a feature unless you
really understand what it is doing. Here is what I recommend:
(1) In one file, put your "compile-time" environment. This includes
macros and readmacros, and special declarations, e.g.
(herald macros)
(defvar helplist)
(defun help-comment-readmacro ()
(push (cons (read) (read)) helplist))
(setsyntax #/~ 'macro 'help-comment-readmacro)
(defmacro helplist-begin ()
(setq helplist ())
(defmacro helplist-end ()
`(defprop help ,helplist comments))
;; Note that I didn't bother with defining a fancy DEFREADMACRO, since
;; it just isn't worth the trouble.
(2) Then your source-file would look like :
(eval-when (eval compile)
(or (get 'macros 'version) (load "macrofile")))
(helplist-begin)
.... stuff stuff stuff ...
(helplist-end)
(3) Do not use the Maclisp string package. It is has proven to
be completely unreliable. An alternative, which has been used in a text
editor written in maclisp, is in "GJC;CHAR >" on MIT-MC.
Someday a reasonable string may be released as part of the Maclisp
distribution, until then you should be able to get by fine with
something like "GJC;CHAR >"
Note that this file should be loaded at COMPILE and RUNTIME,
since it includes declarations, readmacros, and code.
-gjc
∂01-Nov-82 1417 David Eppstein <CSD.Kronj at SU-SCORE> SUBFORK module (LEDIT)
Date: 1 Nov 1982 0055-PST
From: David Eppstein <CSD.Kronj at SU-SCORE>
Subject: SUBFORK module (LEDIT)
To: Bug-LISP at MIT-MC
The lines in SI:GIVUP-TTYINTS that set the inferior fork's capabilities
are switched, so that the fork gets no caps, causing LEDIT to lose big.
Old code:
(jsys #.EPCAP handle
(boole 2 1←18 cap←inferior)
(boole 2 1←18 cap←poss←inf)
1)
Correct code:
(jsys #.EPCAP handle
(boole 2 1←18 cap←poss←inf)
(boole 2 1←18 cap←inferior)
1)
David
-------
∂03-Nov-82 2158 JONL at PARC-MAXC 4th level indirection -- maybe you haven't yet seen this?
Date: 3 NOV 1982 2058-PST
From: JONL at PARC-MAXC
Subject: 4th level indirection -- maybe you haven't yet seen this?
To: info-lisp at MIT-AI, info-lispm at MIT-AI
cc: gls at MIT-AI, rpg at MIT-MC
Date: 3 Nov. 1982 1:49 pm PST (Wednesday)
From: Treichel.PA
Subject: Lisp Song
To: CIS↑
Reply-To: Treichel
Have you seen this?
Jeanie
---------------------------
Date: 3 Nov. 1982 4:23 pm EST (Wednesday)
From: Gafter.Henr
Subject: LISP song
To: AllWhimsy↑.pa, Language↑, Gottwald, KAnderson
cc: Gafter
This was in the uucp bboard net.jokes recently.
-------------------------------------------------------
From decvax!utzoo!utcsrgv!roderick Mon Nov 1 14:24:35 1982
Another Glitch in the Call
------- ------ -- --- ----
(Sung to the tune of a recent Pink Floyd song.)
We don't need no indirection
We don't need no flow control
No data typing or declarations
Hey! Did you leave the lists alone?
Chorus:
All in all, it's just a pure-LISP function call.
We don't need no side effect-ing
We don't need no scope control
No global variables for execution
Hey! Did you leave those args alone?
(Chorus)
We don't need no allocation
We don't need no special nodes
No dark bit-flipping in the functions
Hey! Did you leave the bits alone?
(Chorus)
We don't need no compilation
We don't need no load control
No link edit for external bindings
Hey! Did you leave that source alone?
(Chorus, and repeat)
------------------------------------------------------------
∂20-Nov-82 1508 GJC at MIT-MC FLAME warning: Scheme broken on OZ today.
Date: Saturday, 20 November 1982 18:03-EST
Sender: GJC at MIT-OZ
From: GJC at MIT-MC
To: GLR at MIT-OZ
Cc: BUG-LISP at MIT-OZ, FEINBERG at MIT-OZ, GJS at MIT-OZ, HAL at MIT-OZ,
HANSON at MIT-OZ, RWK at SCRC
Subject: FLAME warning: Scheme broken on OZ today.
In-reply-to: The message of 20 Nov 1982 15:43-EST from GLR
You would patch Maclisp without knowing who was doing maintenance and
where the canonical sources are? Sigh...
As of now there is no Local Maclisp maintenance, and no canonical sources.
When OZ came up I was to install Maclisp here from sources on MC and XX,
but instead MARTY cleverly arranged for people outside of MIT and the LAB to
"help him out" thereby contributing to the present inconsistent mess.
However, things seemed to run anyway, so it wasn't worth hassling, considering
the amount of other work to do on other projects.
On the other hand, when I try to run SCHEME on OZ to verify examples run
in other implementations (in this case on the VAX), I don't like to end up
spending lots of time hassling MACLISP and lack of DISK SPACE on OZ.
(Who ?designed? the present disk-structure settup here anyway?
With all those RP06's, why are we losing? Doesn't anybody GFR?)
If you have problems with Maclisp on TOPS-20, first try to get around
them by loading LISP-LEVEL stuff, and dumping out your own version using SHARE.
The mere fact that you had INTERLOCK problems with trying to patch LISP.EXE
should have told you that somebody was depending on it.
The present problem is just that the most experienced Maclisp user/implementor
people here at the labs don't find it worthwhile to fix maclisp bugs in
the MIDAS sources. Mainly because they are responsible for or depend on
stable large systems in the present versions of Maclisp, and because they
have new implementations of lisp systems to work on.
To push forward the maclisp world for the sake of small changes is
conterproductive, as a small time spent by inexperienced hackers
can force the spending of considerable time by experienced hackers.
This is a very expensive form of MAKE-WORK. (Real $$$ expensive too.)
-GJC
p.s. In other words. Cool it for a while in the Maclisp directory.
After the Thanksgiving break you can talk with GSB, myself, and others
about what changes are really needed.
∂20-Nov-82 1932 David C. Plummer <DCP at MIT-MC> Re: Scheme broken on OZ today.
Date: 20 November 1982 22:25-EST
From: David C. Plummer <DCP at MIT-MC>
Subject: Re: Scheme broken on OZ today.
To: RWK at SCRC-TENEX
cc: GJC at MIT-MC, GLR at MIT-OZ, FEINBERG at MIT-OZ, HAL at MIT-OZ,
GJS at MIT-OZ, HANSON at MIT-OZ, BUG-LISP at MIT-OZ
You want to make separate code and data spaces for the current
MACLISP, do you?? Well, FORGET IT!!! Perhaps you should get
Gorin's book on TWENEX assembler and read the section on extended
addressing.
Basically, CAR and CDR won't work. Well, it might have a prayer
if the CODE for CAR and CDR were in the DATA section. This goes
for all other code that does a CAR or CDR. Well, then again, you
might be able to get around that by making CAR and CDR be two
instructions instead of one. The second instruction would set
the left half to be the DATA section. Kludge, kludge, kludge.
Now what about all those other primitive LISP operators??
That is not the right solution. The right solution is to
reimplement 'Lisp' for extended addressing machines. For 2060's
this would give you 31 address spaces (assuming you can't do much
useful stuff in section 0). On the Jupiter I think the number
jumps to 4095 (and then all you need is several dozen disk drives
for paging).
I know of at least one effort to write an extended addressing
superset of Common Lisp. How much MACLisp code will need to be
modified or rewritten probably depends on how well it was written
for portability in the first place.
My feable knowledge of Common Lisp forces me to make the
following warnings:
* Expect your programs to get bigger. CONSes will take up two
words instead of one.
* Fixnums may shrink to 32 (or even 30) bits. Overflow will cons
bignums.
* Expect arithmetic operations to slow down. I think Common Lisp
does generic arithemetic. If so, a simple + on non-declared
numbers needs to check the arguments and value (even in compiled
code).
∂21-Nov-82 2357 Martin David Connor <MARTY at MIT-MC> A minor update for Top-20 Maclisp
Date: 22 November 1982 02:46-EST (Monday)
Sender: MARTY at MIT-OZ
From: Martin David Connor <MARTY at MIT-MC>
To: GSB at ML
Subject: A minor update for Top-20 Maclisp
Cc: Bug-Lisp at MC
I found the following in MC:L;STATUS >
Specifically in the (sstatus ttyint ... ) code:
...
SSTIN1: HRRM B,(TT)
...
IFN D20,[
POP P,TT ;RESTORE TTSAR
ROT F,1 ;RESTORE CHARACTER
CAIE F,3 ;DON'T ALLOW USE TO ASSIGN ↑C
==> CAILE F,26. ;TOPS-20 ONLY SUPPORTS TO ↑Z
| JRST UNLKTRUE ;RETURN TRUE, BUT DON'T DO TELL THE OP SYS
| ...
|
= Well, this perhaps used to be true, but is no longer. these days,
one can assign several other characters.
I think the update I would suggest is to remove the test altogether,
since the bit values for the interrupt word on the 20 after the
altmode would have to be special cased.
For my particular application I need to get control at interrupt
I made myself a patched lisp until this is changed, and I indeed am
able to get the altmode interrupt properly.
∂19-Dec-82 1947 JONL at PARC-MAXC Re: (\ x 0) revisited, revisited, revisited
Date: 19 DEC 1982 1945-PST
From: JONL at PARC-MAXC
Subject: Re: (\ x 0) revisited, revisited, revisited
To: ALAN at MIT-MC
cc: BUG-LISP at MIT-MC, GSB at MIT-ML, JONL
In response to your message sent 19 December 1982 21:00-EST
It has always been the case that MacLisp's "single-character"
arithmetic functions were driven by the desire for open-compilation.
Thus one gives up any interpreter error checking in the compiled
code, merely accepting what the hardware returns. It's certainly
no surprise, then, that the PDP10 does odd things with division by
zero -- or do I mistake the tone of your note?
By the bye, I had to bring in the generic operation, since the
"right" thing for the \ subr to do is to cause an error when
given a 0 divisor (just as it would if you gave it NIL for an arg);
unfortunately, this may not be the right thing to do to "fix" the
REMAINDER function: see the caveat in my previous msg.
∂19-Dec-82 2023 Glenn S. Burke <GSB at MIT-ML> Re: Re: (\ x 0) revisited, revisited, revisited
Date: 19 December 1982 23:20-EST
From: Glenn S. Burke <GSB at MIT-ML>
Subject: Re: Re: (\ x 0) revisited, revisited, revisited
To: jonl at PARC-MAXC
cc: BUG-lisp at MIT-MC
No, the whole point of this proposal is that the "right" thing to do
is not to cause an error for a zero divisor, but to check for that
and "do the right thing". This is predicated on the premise that for
the REMAINDER operation, a 0 divisor has a defined result.
(Presumably someone else once thought this, given that the REMAINDER
function has this check.)
The \ function is not an interface to the second value returned by the
IDIV instruction. Our semantics are just that the interpreted version
will behave compatibly with the compiled one. If it takes an extra
couple of instructions to do it right, then great. (HAULONG takes a
couple instructions, as do some of the fix-float conversions.)
∂26-Dec-82 1917 PB e-subjob communication
To: BUG-e, BUG-lisp
What happens when a subjob has lots of output for a window that you are not
looking at? If, as I assume, it suspends the job once some small buffer
is filled, this is a lose, since I often want to get a bunch of output while
doing something else. Or am I wrong, and I can do that?
∂08-Jan-83 1147 EB @ MIT-MC
Date: Saturday, 8 January 1983 14:36-EST
Sender: EB @ MIT-OZ
From: EB @ MIT-MC
To: Bug-Lisp @ MIT-OZ
Does OZ have the latest Maclisp? Lisp 2129, which is installed there,
still has the bug wherein it opens JFNs in restricted mode.
∂11-Jan-83 1506 EB @ MIT-MC
Date: Tuesday, 11 January 1983 13:46-EST
Sender: EB @ MIT-OZ
From: EB @ MIT-MC
To: Bug-Lisp @ MIT-OZ
There is no ALARMCLOCK function in Lisp 2129 on Oz. Is the lack of
ALARMCLOCK permanent?
∂21-Jan-83 1441 JOSHM at MIT-OZ How do I...
Date: 21 Jan 1983 1737-EST
From: JOSHM at MIT-OZ
Subject: How do I...
To: info-lisp at MIT-OZ
cc: bug-lisp at MIT-OZ, bug-scheme at MIT-OZ, info-scheme at MIT-OZ
How do turn off input echoing from inside maclisp or scheme? I'm
writing a display oriented program and the typed input keeps destroying
the display.
-Josh
-------
∂21-Jan-83 1448 JOSHM at MIT-OZ at MIT-MC How do I...
Date: 21 Jan 1983 1737-EST
From: JOSHM at MIT-OZ at MIT-MC
Subject: How do I...
To: info-lisp at MIT-OZ at MIT-MC
cc: bug-lisp at MIT-OZ at MIT-MC, bug-scheme at MIT-OZ at MIT-MC,
info-scheme at MIT-OZ at MIT-MC
How do turn off input echoing from inside maclisp or scheme? I'm
writing a display oriented program and the typed input keeps destroying
the display.
-Josh
-------
∂21-Jan-83 1850 Feinberg@CMU-CS-C How do I...
Received: ID <FEINBERG@CMU-CS-C>; 21 Jan 83 21:43:21 EST
Date: 21 Jan 83 21:43:19 EST
From: Feinberg@CMU-CS-C
To: JOSHM%MIT-OZ@MIT-MC
Cc: bug-lisp%MIT-OZ@MIT-MC, bug-scheme%MIT-OZ@MIT-MC
Subject: How do I...
In-reply-to: The message of 21 Jan 1983 17:37-EST from JOSHM at MIT-OZ at MIT-MC
Hi.
Load <MACLISP>TTY.FASL, and use DO-WITH-TTY-OFF, like so:
(DO-WITH-TTY-OFF <form1> <form2> ... <formn>) ;Like a PROGN with echo
--Chiron
∂14-Feb-83 2041 Communications Satellite <COMSAT @ MIT-MC> Msg of Monday, 14 February 1983 20:12 EST
Received: from SRI-AI by SU-AI with NCP/FTP; 14 Feb 83 20:40:24 PST
Received: from MIT-MC.ARPA by SRI-AI.ARPA with TCP; Mon 14 Feb 83 18:27:43-PST
Date: 14 February 1983 21:02 EST
From: Communications Satellite <COMSAT @ MIT-MC>
Subject: Msg of Monday, 14 February 1983 20:12 EST
To: MacLisp @ SRI-AI
ReSent-date: Mon 14 Feb 83 20:38:37-PST
ReSent-from: MacLisp Hackers <MacLisp@SRI-AI.ARPA>
ReSent-to: buglisphack@SU-AI.ARPA
FAILED: BUGLISPHACK at SU-AI; Host appears to be permanently down or not accepting mail.
Failed message follows:
-------
Received: from SRI-AI.ARPA by SU-SCORE.ARPA with TCP; Mon 14 Feb 83 14:43:12-PST
Date: Mon 14 Feb 83 14:40:50-PST
From: MacLisp Hackers <MacLisp@SRI-AI.ARPA>
Subject: Re: I really don't know where to send this one...
To: NCP.EGK@SU-GSB-HOW.ARPA, Bug-Oz%mit-Oz@SU-SCORE.ARPA,
Bug-Lisp%MIT-Oz@SU-SCORE.ARPA, daniel%mit-Oz@SU-SCORE.ARPA,
Gumby%mit-Oz@SU-SCORE.ARPA
In-Reply-To: Your message of Sun 13 Feb 83 13:15:11-PST
There ISN'T a SYS:MACLISP.EXE on OZ!
-------
∂05-Apr-83 1711 Alan Bawden <ALAN @ MIT-MC> buglisphack@sail
Received: from USC-ECL by SU-AI with NCP/FTP; 5 Apr 83 17:11:14 PST
Received: from MIT-MC by USC-ECL; Tue 5 Apr 83 17:08:35-PST
Date: 4 April 1983 14:12 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: buglisphack@sail
To: SAILBUGLISPHACK @ MIT-MC
I redirected all entries in our mailing lists file for buglisphack to
indirect through usc-ecl. You should start recieving bug-lisp (etc.) mail
again, and I should stop getting complaints from the mailer.
∂05-Apr-83 1911 George J. Carrette <GJC @ MIT-MC> LOOP macro expansions into LET
Received: from USC-ECL by SU-AI with NCP/FTP; 5 Apr 83 19:11:19 PST
Received: from MIT-MC by USC-ECL; Tue 5 Apr 83 19:04:39-PST
Date: 5 April 1983 22:05 EST
From: George J. Carrette <GJC @ MIT-MC>
Subject: LOOP macro expansions into LET
To: DCP @ SCRC-TENEX
cc: BUG-LISP @ MIT-MC, BUG-LOOP @ MIT-ML, GSB @ MIT-ML,
BSG @ SCRC-TENEX, bug-Lispm @ SCRC-TENEX
In-reply-to: Msg of 5 Apr 1983 19:23-EST from DCP at SCRC-TENEX
In PDP-10 maclisp, if you wanted to take up GSB's suggestion, you
could have LET and LET* in the interpreter autoload "LIBLSP;LETFEX FASL"
which is an implementation of LET optimized for the interpreter,
it defines 'em as FEXPRs. Not only is it fast and cons no extra
storage, it is about 1/6 the size of the macro let implementation,
and comes with a money-back guarantee..
∂05-Apr-83 2251 David C. Plummer <DCP@SCRC-TENEX> LOOP macro expansions
Received: from USC-ECL by SU-AI with NCP/FTP; 5 Apr 83 22:51:05 PST
Received: from MIT-MC by USC-ECL; Tue 5 Apr 83 22:49:55-PST
Received: from SCRC-MYSTIC by SCRC-TENEX with CHAOS; Wed 6-Apr-83 01:11:38-EST
Date: Wednesday, 6 April 1983, 01:07-EST
From: David C. Plummer <DCP@SCRC-TENEX>
Subject: LOOP macro expansions
To: BUG-lisp@MIT-MC, bug-Lispm@SCRC-TENEX, BUG-LOOP@MIT-ML
Cc: BSG@SCRC-TENEX, GSB@MIT-ML
In-reply-to: The message of 5 Apr 83 19:23-EST from DCP at SCRC-TENEX
Small warning to those who put my suggestion in their private versions
of LOOP: Be sure to also get the EVAL-WHEN at the beginning of the file
that sets up all the features/non-features. Failure to do this will,
among other things, cause collection to fail on the LispM. I just found
this out the hard way...
∂07-Apr-83 0125 Alan Bawden <ALAN @ MIT-MC>
Received: from USC-ECL by SU-AI with NCP/FTP; 7 Apr 83 01:25:01 PST
Received: from MIT-MC by USC-ECL; Thu 7 Apr 83 01:23:03-PST
Date: 7 April 1983 04:24 EST
From: Alan Bawden <ALAN @ MIT-MC>
To: BUG-LISP @ MIT-MC
Is LISP:LISP.SYMBOLS.2129 not the place I should expect to find the symbols
for MacLisp version 2129 currently running on OZ? They don't appear to be
correct.
∂07-Apr-83 0234 Alan Bawden <ALAN@MIT-OZ> I though we fixed this?
Received: from USC-ECL by SU-AI with NCP/FTP; 7 Apr 83 02:34:47 PST
Received: from MIT-MC by USC-ECL; Thu 7 Apr 83 02:30:24-PST
Date: Thu, 7 Apr 1983 05:17 EST
From: Alan Bawden <ALAN@MIT-OZ>
To: bug-lisp@MIT-OZ
Subject:I though we fixed this?
In my current lisp job on OZ:
(status ttysize)
(30 . -117)
Is this a "fixed in the source but not patched"?
∂08-Apr-83 2325 Alan Bawden <ALAN @ MIT-MC> Gratuitous optimization
Received: from USC-ECL by SU-AI with NCP/FTP; 8 Apr 83 23:25:33 PST
Received: from MIT-MC by USC-ECL; Fri 8 Apr 83 23:22:29-PST
Date: 9 April 1983 02:23 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: Gratuitous optimization
To: BUG-COMPLR @ MIT-MC
I note that < has an optimizer that causes (< 1 x 8) to compile as one might
expect, while in the interpreter this is an error....
∂11-Apr-83 2051 Kent M. Pitman <KMP @ MIT-MC>
Received: from USC-ECL by SU-AI with NCP/FTP; 11 Apr 83 20:51:39 PST
Received: from MIT-MC by USC-ECL; Mon 11 Apr 83 18:08:52-PST
Date: 11 April 1983 21:08 EST
From: Kent M. Pitman <KMP @ MIT-MC>
To: bagley @ MIT-OZ
cc: BUG-LISP @ MIT-MC
Use ((LMLIB) LISPM) for now. Some of that stuff will become autoloading
in a Lisp release soon, I think.
∂11-Apr-83 2052 Kent M. Pitman <KMP @ MIT-MC>
Received: from USC-ECL by SU-AI with NCP/FTP; 11 Apr 83 20:52:02 PST
Received: from MIT-MC by USC-ECL; Mon 11 Apr 83 18:11:32-PST
Date: 11 April 1983 21:08 EST
From: Kent M. Pitman <KMP @ MIT-MC>
To: bagley @ MIT-OZ
cc: BUG-LISP @ MIT-MC
oops. i meant ((LIBLSP) LISPM).. sorry 'bout the confusion.
--kmp
∂11-Apr-83 2323 Pandora B. Berman <CENT @ MIT-ML> file migrated
Received: from USC-ECL by SU-AI with NCP/FTP; 11 Apr 83 23:23:42 PST
Received: from MIT-MC by USC-ECL; Mon 11 Apr 83 23:19:39-PST
Date: 12 April 1983 02:19 EST
From: Pandora B. Berman <CENT @ MIT-ML>
Subject: file migrated
To: bug-lisp @ MIT-OZ
dumper was trying to send this, but didn't know who to send it to. to
tell it, create a file called DIRECTORY.OWNER. which contains the name
of someone responsible for the dir; then dumper will send to that
person.
----------
Date: 11 Apr 1983 0538-EST
From: The Mailer Daemon <Mailer@MIT-OZ>
To: <TU77-MAN@MIT-OZ>
Subject: Message of 11-Apr-83 05:35:32
Message failed for the following:
LIBLSP@MIT-OZ: No such mailbox
------------
Date: 11-Apr-83 05:35:32
From: DUMPER
To: LIBLSP
Subject: Migrated files
The following files have been migrated:
PS:<LIBLSP>APROPOS.FASL.1
-------
∂13-Apr-83 2209 Dave Touretzky at CMU-CS-A CMU MacLisp broken
Received: from USC-ECL by SU-AI with NCP/FTP; 13 Apr 83 22:08:37 PST
Received: from MIT-MC by USC-ECL; Wed 13 Apr 83 22:05:22-PST
Date: 14 April 1983 0101-EST
From: Dave Touretzky at CMU-CS-A
To: bug-lisp at MIT-MC
Subject: CMU MacLisp broken
CC: Scott Fahlman <FAHLMAN at CMU-CS-C>,
Leonard Zubkoff <Zubkoff at CMU-CS-C>,
Neal Feinberg <feinberg at CMU-CS-C>, Richard Goldschmidt at CMU-CS-A
CMU recently, with no prior warning, changed the name of its primary TOPS-10
machine from CMU10A to CMUCSA. As a result, MacLisp no longer recognizes us
as a CMU site: (STATUS OPSYSTEM-TYPE) returns TOPS-10 instead of CMU. This
has in turn broken some of the code in the CMU MacLisp programming
environment.
I traced the problem to two lines of code a couple of screenfuls past the
label D10SET. The solution is to replace the string "CMU10" with the string
"CMUCS" where it appears on those two lines.
Would somebody like to make the change in the sources?
-- Dave Touretzky
∂17-Apr-83 1349 PASIEKA@MIT-OZ Pretty-Printer
Received: from USC-ECL by SU-AI with NCP/FTP; 17 Apr 83 13:49:22 PST
Received: from MIT-MC by USC-ECL; Sun 17 Apr 83 13:48:04-PST
Date: Sun, 17 Apr 1983 14:43 EST
From: PASIEKA@MIT-OZ
To: INFO-MACLISP@MIT-OZ
Subject: Pretty-Printer
I am trying to use the gobble code found in ksb on ml. In
trying to do this I have come up against the problem of transporting
the code to oz and making it work with the various hooks to pretty
print the objects created by the gobble functions. This has problems
when I try to move the code from the format directory on ml to oz.
Does anyone know if it is possible to transport this system to oz and
would they be willing to give me some help in doing so?
Thanks.
-- Mike
∂18-Apr-83 2004 WILLIS@MIT-ML
Received: from USC-ECL by SU-AI with NCP/FTP; 18 Apr 83 20:04:34 PST
Received: from MIT-MC by USC-ECL; Mon 18 Apr 83 20:04:22-PST
From: WILLIS@MIT-ML
Date: 04/18/83 23:04:55
WILLIS@MIT-ML 04/18/83 23:04:55
To: (BUG LISP) at MIT-ML
CC: WILLIS at MIT-ML
I have been trying for some time to print out text files on a printer
connected to my ADDS Viewpoint terminal.
At the cost of great pain and agony I managed (I think) to write a tiny
LISP program to send a file to the terminal without using the ITS PRINT
utility, since this does various things intended for the terminal which
foul up the printer output.
Imagine my shock and horror to find that (apparently) even the tyo subr
goes via CRTSTY, and therefore does annoying things like outputting
spaces (ASCII 32.) as cursor control characters.
Is there a LISP subr which sends absolutely nothing but the given ASCII
code to my modem? Alternatively, is there a system variable which I
can reset to make the system think (temporarily) that I have a totally
dumb terminal?
∂18-Apr-83 2117 Kent M. Pitman <kmp at MIT-MC> WILLIS@ML's TYO gripe
Received: from USC-ECL by SU-AI with NCP/FTP; 18 Apr 83 21:17:51 PST
Received: from MIT-MC by USC-ECL; Mon 18 Apr 83 21:17:05-PST
Date: Tuesday, 19 April 1983, 00:08-EST
From: Kent M. Pitman <kmp at MIT-MC>
Subject: WILLIS@ML's TYO gripe
To: bug-lisp at mc
I sent him a note suggesting he look into IMAGE mode I/O.
∂18-Apr-83 2129 Alan Bawden <ALAN @ MIT-MC> IMAGE mode IO
Received: from USC-ECL by SU-AI with NCP/FTP; 18 Apr 83 21:29:38 PST
Received: from MIT-MC by USC-ECL; Mon 18 Apr 83 21:25:43-PST
Date: 19 April 1983 00:17 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: IMAGE mode IO
To: WILLIS @ MIT-ML
cc: BUG-LISP @ MIT-ML
In-reply-to: Msg of 04/18/83 23:04:55 from WILLIS at MIT-ML
Well, its a real feature of ITS that the system always presents programs
with a virtual terminal so that they don't have to know the peculiarities
of the user's actual terminal. LISP is no exception to thiv@∞@≠∀≠M9$4)$4)4(4)94)%QL4)QQd%5¬≥∀%4)QQd4)→1%M@αode by doing:
(OPEN '|TTY:| '(OUT TTY IMAGE))
This form returns a file-object. Save that file-object and pass it to the
TYO function as a second argument. Then whatever you passed as the first
argument, should be sent directly to your device..
∂11-May-83 0928 @USC-ECL,@MIT-MC:SMATT@MIT-OZ LOOP CONTINUE STATEMENT
Received: from USC-ECL by SU-AI with TCP/SMTP; 11 May 83 09:26:56 PDT
Received: from MIT-MC by USC-ECL; Tue 10 May 83 23:04:47-PDT
Date: Wednesday, 11 May 1983, 01:58-EDT
From: Matt BenDaniel <SMATT@MIT-OZ>
Subject: LOOP CONTINUE STATEMENT
To: bug-LISPM@MIT-OZ, LISP-FORUM@MIT-OZ, dove@MIT-DSPG
In-reply-to: The message of 14 Apr 83 10:14-EST from Webster Dove <dove at MIT-DSPG>
I'd also be very interested in hearing answers to the following question:
Return-path: <dove@MIT-DSPG>
Date: Thursday, 14 April 1983, 10:14-EST
From: Webster Dove <dove at MIT-DSPG>
To: info-LISPM at MIT-OZ
Is there a way in (loop ...) to say
"go directly to the next iteration. Do not execute the remaining
clauses of the body"
Such statements typically are called "continue" or "next"
I have encountered many situations where such a statement would be
useful.
∂11-May-83 0931 @USC-ECL,@MIT-MC:MOON@SCRC-TENEX LOOP CONTINUE STATEMENT
Received: from USC-ECL by SU-AI with TCP/SMTP; 11 May 83 09:29:48 PDT
Received: from MIT-MC by USC-ECL; Wed 11 May 83 00:03:00-PDT
Date: Wednesday, 11 May 1983 02:43-EDT
From: MOON at SCRC-TENEX
To: Matt BenDaniel <SMATT at MIT-OZ>
Cc: bug-LISPM at MIT-OZ, dove at MIT-DSPG, LISP-FORUM at MIT-OZ
Subject: LOOP CONTINUE STATEMENT
In-reply-to: The message of 11 May 1983 01:58-EDT from Matt BenDaniel <SMATT@MIT-OZ>
Date: Wednesday, 11 May 1983, 01:58-EDT
From: Matt BenDaniel <SMATT@MIT-OZ>
I'd also be very interested in hearing answers to the following question:
Date: Thursday, 14 April 1983, 10:14-EST
From: Webster Dove <dove at MIT-DSPG>
Is there a way in (loop ...) to say
"go directly to the next iteration. Do not execute the remaining
clauses of the body"
Such statements typically are called "continue" or "next"
I have encountered many situations where such a statement would be
useful.
Date: Thursday, 14 April 1983 17:27-EST
From: MOON at SCRC-TENEX
In-reply-to: The message of 14 Apr 1983 10:14-EST from Webster Dove <dove at MIT-DSPG>
There isn't now. Normally one encloses the body in a conditional
(unfortunately, it can be painful to do this currently if the body
includes COLLECT statements). The main problem with having a continue
statement is that it may be unclear just what is regarded as "the body"
and what is regarded as "the iteration framework": If there is a WHILE
statement later in the LOOP than the CONTINUE, should it be skipped
or should it still be executed? And is the answer to this affected by
whether there is a DO after the WHILE?
∂11-May-83 1022 @USC-ECL,@MIT-MC:SMATT@MIT-OZ LOOP CONTINUE STATEMENT
Received: from USC-ECL by SU-AI with TCP/SMTP; 11 May 83 10:21:33 PDT
Received: from MIT-MC by USC-ECL; Wed 11 May 83 00:29:53-PDT
Date: Wednesday, 11 May 1983, 03:25-EDT
From: Matt BenDaniel <SMATT@MIT-OZ>
Subject: LOOP CONTINUE STATEMENT
To: MOON@SCRC-TENEX, SMATT@MIT-OZ
Cc: bug-LISPM@MIT-OZ, dove@MIT-DSPG, LISP-FORUM@MIT-OZ
In-reply-to: The message of 11 May 83 02:43-EDT from MOON at SCRC-TENEX
A CONTINUE statement should mean skipping executing any code lexically
after it on the current iteration. This could, of course, be a problem
in the following:
. . . (loop for x = 0 then (1+ x)
IF (> x 3)
CONTINUE
until (> x 7))
However, this is the problem of the coder. If there are other reasons
why implementing (or specifying) the function of a CONTINUE statement,
how about constraining the location of an IF-CONTINUE sequence in a
LOOP body in a manner similar to the IF-DO sequence, where iteration is
not allowed to follow body code. Also, what about a CONTINUE-NAMED
feature for NAMED loops?
∂14-May-83 1416 @USC-ECL,@MIT-MC:KMP@MIT-OZ <LIBLSP>TTY.LSP.24 fixes bugs in <LIBLSP>TTY.KMP.20
Received: from USC-ECL by SU-AI with TCP/SMTP; 14 May 83 14:16:37 PDT
Received: from MIT-MC by USC-ECL; Sat 14 May 83 14:13:40-PDT
Date: Sat, 14 May 1983 17:01 EDT
From: KMP@MIT-OZ
To: BUG-LISP@MIT-OZ
cc: PHW@MIT-OZ
Subject: <LIBLSP>TTY.LSP.24 fixes bugs in <LIBLSP>TTY.KMP.20
PHW tried to use my TTY package (containing DO-WITH-TTY-ON,
DO-WITH-TTY-OFF, etc) and found it broken because the FASL file
was trying to INCLUDE LISP:SUBLOAD. The reason it was trying to
do this was to get around some hassle with SI:GEN-LOCAL-VARIABLE,
which JONL had patched the source to use in place of GENSYM.
The reason the INCLUDE happened at the wrong time was because
someone wrote (IF (STATUS FEATURE ITS) (INCLUDE ...) (INCLUDE ...))
instead of (INCLUDEF (IF ...)).
The macros in this file are the sort that other macros do not expand
into. They are the kind of thing which programs expand into and as
such, with the exception of a few cases of "#%", GENSYM is completely
reasonable and has no problems about it.
In any case, I have seen far too many bugs caused by the fact that
these things do not primitively autoload and I don't think it's worth
using either GENTEMP or SI:GEN-LOCAL-VARIABLE unless they become primitively
available. They are inappropriate for use in libraries which are not
maintained as an essential feature of the system until they are primitively
accessible.
I would appreciate if people would refrain from adding stupid little
"features" like this to my libraries without at least telling me that
they have done so and without checking that the "features" work. I tend
to check the software I release relatively carefully and this sort of
thing gives my software a bad name. In this case, the FASL file wouldn't
even LOAD so it's quite clear that no one had tested it.
I wrote OZ:PS:<LIBLSP>TTY.LSP.24 and compiled it. It seems to work fine.
Please report bugs.
By the way, this version also includes another macro called BIND-TTYINT
which allows a let-style syntax for binding TTYINT things. eg,
(BIND-TTYINT ((#↑B NIL) (#↑H #↑B)) ...body...)
binds ↑B to no interrupt and Backspace to work like ↑B for the invocation
of the BODY.
I'll copy this back to ITS later today in case anyone finds it easier to
pick up the new versions from there than from here.
--kmp
∂14-May-83 1632 @USC-ECL:KMP@MIT-MC
Received: from USC-ECL by SU-AI with TCP/SMTP; 14 May 83 16:32:17 PDT
Received: from MIT-MC by USC-ECL; Sat 14 May 83 15:19:58-PDT
Date: 14 May 1983 18:17 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
To: INFO-MACLISP @ MIT-MC
I added a macro called BIND-TTYINT to the TTY package on LIBLSP.
It binds the TTYINT status of one or more characters within a given
dynamic scope. Sample calling sequence is
(BIND-TTYINT ((#↑B NIL) ;disable control-B
(#↑↑ #↑G) ;make control-↑ like control-G
(#↑H #'FOO)) ;make control-H (Backspace) handled by function FOO
...body...)
To get these fixes outside of MIT, Lisp maintainers need to pick up
version 24 of ((LIBLSP) TTY).
--kmp
∂15-May-83 0920 @USC-ECL,@MIT-MC:GJC@MIT-MC <LIBLSP>TTY.LSP.24 fixes bugs in <LIBLSP>TTY.KMP.20
Received: from USC-ECL by SU-AI with TCP/SMTP; 15 May 83 09:11:15 PDT
Received: from MIT-MC by USC-ECL; Sun 15 May 83 09:06:28-PDT
Date: 15 May 1983 12:02 EDT
From: George J. Carrette <GJC @ MIT-MC>
Subject: <LIBLSP>TTY.LSP.24 fixes bugs in <LIBLSP>TTY.KMP.20
To: KMP @ MIT-OZ
cc: BUG-LISP @ MIT-OZ, PHW @ MIT-OZ
In-reply-to: Msg of Sat 14 May 1983 17:01 EDT from KMP at MIT-OZ
I could have sworn that I diked out the SUBLOAD and SI:GENTEMP stuff
from TTY a while ago. Indeed, check out LIBDOC;TTY 19, which was
written in NOV '82. At least the FASL for this was moved to OZ also,
when I found I got screwed by missing autoload files. Evidently the OZ
version was further hacked later on by someone else, reintroducing the
lossage. Blame me for not moving the source to OZ also.
N.B. All those who would hack Maclisp on OZ: The sources to Maclisp have
not ever been considered to be on OZ. The software was installed by
"helpful" outsiders before responsible local maclisp hackers could act.
Since then it has been fun to watch. Kent, if it weren't for people like
you fixing up things maybe we could have the total collapse that would
lead to a fresh start though?
-gjc
∂26-May-83 2214 @USC-ECL,@MIT-MC:ALAN@MIT-OZ Yuch!
Received: from USC-ECL by SU-AI with TCP/SMTP; 26 May 83 22:14:27 PDT
Received: from MIT-MC by USC-ECL; Thu 26 May 83 22:11:40-PDT
Date: Fri, 27 May 1983 01:08 EDT
From: Alan Bawden <ALAN@MIT-OZ>
To: bug-lisp@MIT-OZ
Subject:Yuch!
I just discovered that the setting of the MAKHUNK switch controls TWO
things at once. Setting it to T makes (makhunk 2) return a hunk (which I
like), and it also makes '(1 . 2 .) return a hunk (which I think sucks, I
would much prefer to get a dot context error). Yuch!
∂04-Jun-83 1636 @USC-ECL,@MIT-MC:SAZ@MIT-OZ binding 't to other things (like nil)
Received: from USC-ECL by SU-AI with TCP/SMTP; 4 Jun 83 16:36:46 PDT
Received: from MIT-MC by USC-ECL; Sat 4 Jun 83 16:35:45-PDT
Date: Saturday, 4 June 1983, 19:32-EDT
From: David M. J. Saslav <SAZ@MIT-OZ>
Subject: binding 't to other things (like nil)
To: bug-lisp@MIT-OZ
I don't think it's a good idea to be able to say (setq 't ni), since this makes forms like
(cond (t 45) (nil 50) ((print "me") 100)) return:
ME
100
∂14-Jun-83 0306 @USC-ECL,@MIT-MC:CENT@MIT-ML files migrated on oz
Received: from USC-ECL by SU-AI with TCP/SMTP; 14 Jun 83 03:06:43 PDT
Received: from MIT-MC by USC-ECL; Tue 14 Jun 83 03:02:45-PDT
From: CENT@MIT-ML
Date: 06/14/83 06:00:30
Subject: files migrated on oz
CENT@MIT-ML 06/14/83 06:00:30 Re: files migrated on oz
To: (BUG LISP) at MIT-ML
if there is someone locally responsible for worrying about this sort
of thing, please create a DIRECTORY.OWNER file on this dir so i
don't have to bother everyone when files get reaped.
----------
Date: 14-Jun-83 02:46:24
From: Dumper <DUMPER@MIT-OZ>
Reply-to: File-Retrieve <FILE-R@MIT-OZ>
To: BUG-BACKUPERS
Subject: Migrated files
The following files have been migrated:
PS:<MACLISP>6003.LISP.4
PS:<MACLISP>LISP.EXE.2131
PS:<MACLISP>TTY.FASL.18
∂14-Jun-83 2302 @USC-ECL,@MIT-MC:VaughanW@HI-MULTICS Call For Papers
Received: from USC-ECL by SU-AI with TCP/SMTP; 14 Jun 83 23:02:05 PDT
Received: from MIT-MC by USC-ECL; Tue 14 Jun 83 22:57:31-PDT
Redistributed-Date: 14 June 1983 22:27 mst
Redistributed-By: VaughanW.REFLECS at HI-MULTICS
Redistributed-To: info-ada at MIT-MC, editor-people at SU-SCORE,
lisp-forum at MIT-MC
Date: 27 May 1983 19:08 mst
From: VaughanW at HI-MULTICS (Bill Vaughan)
Subject: Call For Papers
To: HUMAN-NETS at RUTGERS
cc: sf-lovers at MIT-AI, info-micro at MIT-MC
Last year at this time I put the Call for Papers for the PC3 conference out to
these mailing lists and bulletin boards. We seemed to get a good response, so
here it is again. Notice that this year's theme is a little different.
Further note that we are formally refereeing papers this year.
If anyone out there is interested in refereeing, please send me a note.
---------------
Third annual Phoenix Conference on Computers and Communications
CALL FOR PAPERS
Theme: THE CHALLENGE OF CHANGE - Applying Evolving Technology.
The conference seeks to attract quality papers with emphasis on the following
areas:
APPLICATIONS -- Office automation; Personal Computers; Distributed systems;
Local/Wide Area Networks; Robotics, CAD/CAM; Knowledge-based systems; unusual
applications.
TECHNOLOGY -- New architectures; 5th generation & LISP machines; New
microprocessor hardware; Software engineering; Cellular mobile radio;
Integrated speech/data networks; Voice data systems; ICs and devices.
QUALITY -- Reliability/Availiability/Serviceability; Human engineering;
Performance measurement; Design methodologies; Testing/validation/proof
techniques.
Authors of papers (3000-5000 words) or short papers (1000-1500 words) are to
submit abstracts (300 words max.) with authors' names, addresses, and
telephone numbers. Proposals for panels or special sessions are to contain
sufficient detail to explain the presentation. 5 copies of the completed
paper must be submitted, with authors' names and affiliations on a separate
sheet of paper, in order to provide for blind refereeing.
Abstracts and proposals due: August 1
Full papers due: September 15
Notification of Acceptance: November 15
Conference Dates: March 19-21, 1984
Address the abstract and all other replies to:
Susan C. Brewer
Honeywell LCPD, MS Z22
PO Box 8000 N
Phoenix AZ 85066
----------------
Or you can send stuff to me, Bill Vaughan (VaughanW @ HI-Multics) and I will
make sure Susan gets it.
∂16-Jun-83 1714 @USC-ECL:ALAN@MIT-MC New MacLisp now installed on MC.
Received: from USC-ECL by SU-AI with TCP/SMTP; 16 Jun 83 17:13:19 PDT
Received: from MIT-MC by USC-ECL; Thu 16 Jun 83 17:08:16-PDT
Date: 16 June 1983 20:05 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: New MacLisp now installed on MC.
To: BUG-LISP @ MIT-MC, INFO-MACLISP @ MIT-MC, (*MSG *MC) @ MIT-MC
I have just installed a new MacLisp (version 2138) on MC forged from the
latest sources. This corresponds almost exactly to the XLISP that has been
available on MC for the last month or so. Since most of the changes to the
sources since the last MacLisp were made (over a year ago) had to do with IO
on 20X, there is little to watch out for. A matching COMPLR has been
installed as well, along with a MACLISP and a SHARABLE built on top of it.
The previous versions of LISP and COMPLR have been renamed to OLISP and
OCOMPLR.
People who maintain dumped systems are encouraged to update their entries
in LISP;LOCK >. I garbage collected quite a few entries myself, and
several dumps are going to disappear from disk soon unless someone speaks
up for them.
∂29-Jun-83 1119 @USC-ECL:CFFK@MIT-MC Cursor positioning with Tops-20 lisp (in Macsyma on XX)
Received: from USC-ECL by SU-AI with TCP/SMTP; 29 Jun 83 11:19:09 PDT
Received: from MIT-MC by USC-ECL; Wed 29 Jun 83 09:40:38-PDT
Date: 29 June 1983 12:38 EDT
From: Charles F. F. Karney <CFFK @ MIT-MC>
Subject: Cursor positioning with Tops-20 lisp (in Macsyma on XX)
To: BUG-LISP @ MIT-MC
cc: JPG @ MIT-MC
If I perform the following code:
(setq tt (open '|tty:| '(tty out image single)))
(defun ttt ()
(mapcar (function (lambda (x) (+tyo x tt)))
'(143. 20. 20. 65. 66. 67. 143. 0. 0.))
(tyi))
(ttt)<space>
Then 'ABC' gets written out at position 20,20 and the
cursror homes. However following this <newlines> don't get
generated. E.g. t<space> ==> T (on the same line).
(cursorpos 'top) clears this condition.
This works OK in ITS..
∂04-Jul-83 1523 @USC-ECL:JGA@MIT-MC a question of interrupts (I guess)
Received: from USC-ECL by SU-AI with TCP/SMTP; 4 Jul 83 15:23:17 PDT
Received: from MIT-MC by USC-ECL; Mon 4 Jul 83 15:18:34-PDT
Date: 4 July 1983 18:17 EDT
From: John G. Aspinall <JGA @ MIT-MC>
Subject: a question of interrupts (I guess)
To: BUG-LISP @ MIT-MC
cc: JGA @ MIT-MC
I have a problem that seems like some sort of synchronization
thing, but I don't really understand it.
The following function queries a Tektronix terminal for its
joystick position.
(defun tek-get-ginput ()
(+tyo #\ALT graphic-output)
(+tyo #\TEK-GINMODE graphic-output)
(prog1 (do-with-tty-off
(list (tyi)
(+ (lsh (logand (tyi) #o37) 5) (logand (tyi) #o37))
(+ (lsh (logand (tyi) #o37) 5) (logand (tyi) #o37))))
(tyi)))
Graphic-output is a output stream, open in image mode, to the tty.
The two-character sequence <alt> <ctrl-z> (#\tek-ginmode is defined as
#o32) puts the Tek in GIN (Graphic INput) mode. The regular cursor
disappears, and is replaced with an arrow. The user points this at
wherever, and hits any key. The Tek transmits a 6 character sequence
- the key typed is first, then four (non-control) characters
containing the coordinates (encoded obviously above), then a <cr>.
The <cr>'s job is to return the Tek to it's previous mode (not GIN
mode) so it ought to be echoed, the other chars probably shouldn't be
echoed, hence the code above.
Now the problem. I put this in a real simple command loop to trace a
pattern on the screen - m:move, d:draw, etc. This thing returns a lisp
form that can be evaluated for the pattern again.
(defun trace ()
(do ((com (tek-get-ginput) (tek-get-ginput))
(form nil))
((or (= (car com) #/q) (= (car com) #/Q)) (cons 'progn (nreverse form)))
(caseq (car com)
((#\FF)
(graphout (page)
(do ((form (reverse form) (cdr form)))
((null form))
(eval (car form)))))
((#/m #/M)
(push (rplaca com 'move) form))
((#/d #/D)
(push (rplaca com 'draw) form))
((#\RUBOUT)
(pop form)))))
This works fine, IF I TYPE SLOWLY ENOUGH. (This, on a 1200 baud
Vadic, MC lightly loaded.) On the other hand, two keystroke commands
within (I would guess) 0.5 second of each other, put it in a state
where it looks as if something's out of synch. Several keystrokes
later, it sometimes returns to normal, having missed all those
commands, but I can't reproduce that reliably.
All suggestions welcome - and thanks in advance.
∂15-Jul-83 1751 @USC-ECL:ALAN@MIT-MC Mustn't call UINT0 from within a PI server
Received: from USC-ECL by SU-AI with TCP/SMTP; 15 Jul 83 17:51:15 PDT
Received: from MIT-MC by USC-ECL; Fri 15 Jul 83 17:48:26-PDT
Date: 15 July 1983 20:46 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: Mustn't call UINT0 from within a PI server
To: BUG-LISP @ MIT-MC, MOON @ MIT-MC, ELLEN @ MIT-MC
Date: 15 July 1983 01:46 EDT
From: V. Ellen Golden <ELLEN>
To: ALAN
Re: BUG LISP????
I have seen this twice now, but the people usually started up
a new MACSYMA. Dave MOON helped RGA to save his, and he (MOON)
thought it was a Lisp problem, so it might be related to the new
lisp.... I send it to you (This is the one MOON fixed...).
Date: 12 July 1983 16:06 EDT
From: V. Ellen Golden <ELLEN @ MIT-MC>
Date: 12 July 1983 12:37 EDT
From: Richard Gregory-Allen <RGA @ MIT-MC>
Here I am in another fix. I was running a Macsyma and had ↑Z'd out to
play around in the editor. When I tried to $P back into my job, I got
the following message;
ERROR; (ATTY;) 65063>>CAME 6,1642 6/ -41,,1642 1642/ -31,,1652
and I'm back at DDT. (I don't remember if the (ATTY;) was
there before I disowned it the first time, I don't think so
though.)
I've got quite a bit of time invested in the session so I'd really love
to be able to rescue it. I've seen this condition before (with
less invested)
though only since this latest version (304) of Macsyma has
been installed. I've disowned the job (jobname is A) in hopes
that you can somehow fix it.
--------------
This error is somehow associated with the "tty handler" and MACSYMA getting
control of the "tty". In general it means that the job is "broken", but
I was able to get Dave MOON to look at it and he managed to get rid
of the interrupt and rescue the MACSYMA. It is now sitting loose in the
system as ELLEN A. To reown it and save out what you want you type
:ujob ellen a
Good luck!
The code near the .LOSE in question:
MOVE T,[-LINTPDL,,INTPDL] ;MUSTN'T CALL UINT0 FROM
CAME T,INTPDL ; WITHIN A PI SERVER
.LOSE
I guess I would like to know what was on the interrupt PDL when this
happens. (Perhaps Moon will tell me.) I can't seem to reproduce this
myself, but it is a little vague just what this guy was doing. (He speaks
of "disowning" as if he thinks that that is what ↑Z does, or perhaps he
isn't telling the whose story.) Next time it happens perhaps someone will
dump the remains on the CRASH; directory for autopsy? (Although I guess
that might not save all the necessary state for something
interrupt-driven.)
In the meantime I guess It's time to learn about how interrupts work.
Perhaps anyone on bug-lisp who might have an idea why any changes made in
the last year should change anything interrupt related (I just examined all
of the recent changes, and I don't see any obvious candidates) should speak
up.
∂15-Jul-83 1927 @USC-ECL,@MIT-MC:GSB@MIT-ML .lose because of intpdl
Received: from USC-ECL by SU-AI with TCP/SMTP; 15 Jul 83 19:26:52 PDT
Received: from MIT-MC by USC-ECL; Fri 15 Jul 83 19:21:48-PDT
From: GSB@MIT-ML
Date: 07/15/83 22:17:45
Subject: .lose because of intpdl
GSB@MIT-ML 07/15/83 22:17:45 Re: .lose because of intpdl
To: ALAN at MIT-ML
CC: (BUG lisp) at MIT-MC
I think i have seen this before, but am not absolutely certain. UINT0B
familiar; this may not be new.
∂16-Jul-83 2233 @USC-ECL:JPG@MIT-MC
Received: from USC-ECL by SU-AI with TCP/SMTP; 16 Jul 83 22:11:13 PDT
Received: from MIT-MC by USC-ECL; Sat 16 Jul 83 22:07:11-PDT
Date: 17 July 1983 01:05 EDT
From: Jeffrey P. Golden <JPG @ MIT-MC>
To: MMMM @ MIT-MC
cc: ELLEN @ MIT-MC, JPG @ MIT-MC, BUG-LISP @ MIT-MC
MMMM@MIT-MC 07/16/83 23:55:43
What does the error code "65063>>CAME 6,1642" mean? If I do get this
error how do i continue working in macsyma. This error takes me to DDT
and :job followed by :continue does not get me back to macsyma.
It appears to be caused by a bug in the tty interrupt routines in the
Lisp that Macsyma is in. I do not know how you continue working with that
Macsyma. (I have not seen this happen myself, but I have heard of its
happening.) If this happens to you again, the best thing you can do is
disown that Macsyma and send a note to BUG-LISP and/or to MACSYM so that
a Lisp expert can study the broken Macsyma in the hopes of figuring out
just what is causing this.
∂19-Jul-83 1917 @USC-ECL,@MIT-MC:BEN@MIT-ML Bug in DO when compiled.
Received: from USC-ECL by SU-AI with TCP/SMTP; 19 Jul 83 19:16:56 PDT
Received: from MIT-MC by USC-ECL; Tue 19 Jul 83 12:36:24-PDT
From: BEN@MIT-ML
Date: 07/19/83 15:28:52
Subject: Bug in DO when compiled.
BEN@MIT-ML 07/19/83 15:28:52 Re: Bug in DO when compiled.
To: (BUG LISP) at MIT-ML
CC: BEN at MIT-ML
A simple iteration using DO, with no global variables or anything
funny, works correctly when interpreted, fails when compiled.
The simple version of the bug is in BEN;DO←BUG > and DO←BUG FASL.
The problem is that the update value for the first DO variable D
behaves as if it had the same expression as the second variable D1.
Even if this cannot be fixed in the visible future, it would be
very valuable to know the nature and extent of this bug.
∂19-Jul-83 1917 @USC-ECL:KMP@MIT-MC
Received: from USC-ECL by SU-AI with TCP/SMTP; 19 Jul 83 19:17:14 PDT
Received: from MIT-MC by USC-ECL; Tue 19 Jul 83 12:58:44-PDT
Date: 19 July 1983 15:50 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
To: BEN @ MIT-ML
cc: BUG-LISP @ MIT-MC
You're right.
(defun f (a b)
(do ((d a d1)
(d1 b (+ d d1)))
((> d 200.))
(print (list 'D= d 'D1= d1))))
compiles wrong. I believe this is a known bug related to number compilation.
I have heard it explained but don't recall the explanation so can't tell you
how to predict it. Perhaps someone else on this list will volunteer it.
In any case, either of
(defun f (a b)
(declare (fixnum a b))
(do ((d a d1)
(d1 b (+ d d1)))
((> d 200.))
(declare (fixnum d d1))
(print (list 'D= d 'D1= d1))))
or
(defun f (a b)
(do ((d a d1)
(d1 b (plus d d1)))
((greaterp d 200.))
(print (list 'd= d 'd1= d1))))
will work for you. Hope this is at least somewhat helpful. Probably you want
the former; the latter is just there for contrast.
∂20-Jul-83 2228 @USC-ECL:ALAN@MIT-MC More bits.
Received: from USC-ECL by SU-AI with TCP/SMTP; 20 Jul 83 22:27:50 PDT
Received: from MIT-MC by USC-ECL; Wed 20 Jul 83 22:27:27-PDT
Date: 21 July 1983 01:18 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: More bits.
To: MMMM @ MIT-MC, JPG @ MIT-MC, ELLEN @ MIT-MC, BUG-LISP @ MIT-MC
Date: 20 July 1983 21:10 EDT
From: Moses Minta <MMMM>
To: BUG-LI
Here is the error which is suspected to be caused by a bug in
tty(lisp?). I was advised to disown the job and send you this message.
Will appreciate any help in solving this mystery. Thanks.
Thanks! Now we have an example to study. I dumped this lisp in
CRASH;LISP TTYRET and recorded the user variables in ALAN;TTYRET VARS if
anyone else would like to take a look at this.
Despite the fact that when this bug usually happens it is a %PJATY
interrupt that is already sitting on INTPDL, in THIS case it seems to be an
interrupt on the TTY: input channel! The thing that all instances do have
in common, however, is that an UNWIND-PROTECT was interrupted out of (look
at the gubble at the top of the stack). [I guess "TTYRET" wasn't a good
name in light of this.]
I still don't understand what is going on here though.
BTW, I have had no trouble $Ging a Macsyma that dies in this way.
∂05-Aug-83 1143 @USC-ECL,@MIT-MC:JUDY@MIT-OZ problem with setting the status of the random function
Received: from USC-ECL by SU-AI with TCP/SMTP; 5 Aug 83 11:43:40 PDT
Received: from MIT-MC by USC-ECL; Fri 5 Aug 83 11:41:20-PDT
Date: Fri, 5 Aug 1983 14:33 EDT
From: JUDY@MIT-OZ
To: bug-maclisp@MIT-OZ
cc: judy@MIT-OZ
Subject: problem with setting the status of the random function
Depending upon the current random seed, Maclisp sometimes gives an
error message of "bad argument" for the call
(sstatus random (status random))
and similarly for something like
(setq foo (status random))
(sstatus random foo)
In particular this will happen (to me at least) after random is called
34 (base 10) times, 70 times, 105 times, 141 times, 176 times, 212
times, etc.
After random has been called 34 times (starting with the initial seed)
(status random) returns (0 36 26091955856 ...).
After 70 times (status random) returns (35 0 26091955856 ...)
105 (0 36 22609952497 ...)
141 (35 0 22609952497 ...)
176 (0 36 -14927067643 ...)
212 (35 0 -14927067643 ...)
If you will notice, 70 is 36 away from 34, 105 is 35 away from 70, 141
is 36 away from 105, etc.
Judy
∂05-Aug-83 1224 @USC-ECL:KMP@MIT-MC Judy's RANDOM bug
Received: from USC-ECL by SU-AI with TCP/SMTP; 5 Aug 83 12:24:43 PDT
Received: from MIT-MC by USC-ECL; Fri 5 Aug 83 12:24:12-PDT
Date: 5 August 1983 15:19 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
Subject: Judy's RANDOM bug
To: BUG-MACLISP @ MIT-MC
I put a function RANDOM-TESTER in the file MC:LSPSRC;RNDTST which will
cause Judy's bug to happen while also printing other useful debugging
info. If/when a fix is made, you might use this function to test the
fix.
As a hunch, I tried just patching SSRAN6+2 to use JUMPL instead of JUMPLE
(in Lisp 2138 on ITS) and this makes my RANDOM-TESTER function happy.
That of course doesn't mean it's the right fix, but it does suggest
that the error checking is probably just overly paranoid since presumably
something coming out of (STATUS RANDOM) has to be a valid input to
(SSTATUS RANDOM).
∂06-Aug-83 0133 @USC-ECL:ALAN@MIT-MC (sstatus random (status random))
Received: from USC-ECL by SU-AI with TCP/SMTP; 6 Aug 83 01:32:59 PDT
Received: from MIT-MC by USC-ECL; Fri 5 Aug 83 19:13:54-PDT
Date: 5 August 1983 22:06 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: (sstatus random (status random))
To: KMP @ MIT-MC, JUDY @ MIT-OZ
cc: BUG-MACLISP @ MIT-MC
In-reply-to: Msg of Fri 5 Aug 1983 14:33 EDT from JUDY at MIT-OZ
Date: Fri, 5 Aug 1983 14:33 EDT
From: JUDY at MIT-OZ
Depending upon the current random seed, Maclisp sometimes gives an
error message of "bad argument" for the call
(sstatus random (status random))
Date: 5 August 1983 15:19 EDT
From: Kent M. Pitman <KMP>
As a hunch, I tried just patching SSRAN6+2 to use JUMPL instead of JUMPLE
(in Lisp 2138 on ITS) and this makes my RANDOM-TESTER function happy.
That of course doesn't mean it's the right fix, but it does suggest
that the error checking is probably just overly paranoid since presumably
something coming out of (STATUS RANDOM) has to be a valid input to
(SSTATUS RANDOM).
Thank you KMP, you are absolutely correct. Fixed in the source. I also
fixed the check at SSRAN6+3 which was a little too liberal about what it
accepted.
[I must look up the reference for this random number generator. It seems
to be different from the LispMachine version in that it steps its pair of
pointers in the opposite direction. I suspect this makes a difference in
the randomness of the result. Of course I can't fix it if people are
depending on (sstatus random 17) doing the same thing next year as
last...]
∂23-Aug-83 1147 @USC-ECL,@MIT-MC:PADGET@UTAH-20 function cells
Received: from USC-ECL by SU-AI with TCP/SMTP; 23 Aug 83 11:47:32 PDT
Received: from MIT-MC by USC-ECL; Tue 23 Aug 83 11:39:14-PDT
Date: 23 Aug 1983 1135-MDT
From: Julian Padget <PADGET@UTAH-20>
Subject: function cells
To: lisp-forum@MIT-MC
cc: Padget@UTAH-20
I am doing a little bit of historical digging on LISP, and I would like
to know who claims responsibility for the invention of the function cell
which is common to so many LISP implementations. Further I would be interested
to hear a justification for both its invention and retention.
--Julian Padget (Padget@Utah-20).
-------
∂23-Aug-83 1424 @USC-ECL,@MIT-MC:Deutsch.PA@PARC-MAXC Re: function cells
Received: from USC-ECL by SU-AI with TCP/SMTP; 23 Aug 83 14:23:46 PDT
Received: from MIT-MC by USC-ECL; Tue 23 Aug 83 14:22:11-PDT
Date: Tue, 23 Aug 83 14:13 PDT
From: Deutsch.PA@PARC-MAXC.ARPA
Subject: Re: function cells
In-reply-to: "PADGET@UTAH-20.ARPA's message of 23 Aug 83 11:35 MDT"
To: Julian Padget <PADGET@UTAH-20.ARPA>
cc: lisp-forum@MIT-MC.ARPA, Bobrow.PA@PARC-MAXC.ARPA,
Teitelman.PA@PARC-MAXC.ARPA
Lisp 1.5 stored function definitions on the property list. To my
knowledge, the first Lisp that used an independent function cell was the
PDP-1 implementation of BBN-Lisp, the precursor of Interlisp. Dan
Bobrow may be able to confirm or add details. This would have been
around 1965. He and I were the principal architects of this system; I
would trust his word about who invented what. You may find other
interesting historical information in the Information International Inc.
Lisp system book, edited by Edmund C. Berkeley and also published
sometime around 1965. It doesn't describe BBN-Lisp, but it describes
some other systems, and one of them may have function cells -- I don't
really remember.
I don't know what alternatives you want a justification with respect to.
The changeover from property list representation was primarily for
efficiency. The distinction between "function context" and "variable
context" for interpreting names was a bad idea inherited from Lisp 1.5:
it was retained for a very long time because doing free variable lookups
for every function name (which are normally only bound at the top level)
would have been atrociously slow. It was only with the invention of
shallow binding that people started to look seriously at re-merging
function and variable binding.
∂30-Aug-83 1738 @USC-ECL,@MIT-MC:Bobrow.PA@PARC-MAXC Re: function cells
Received: from USC-ECL by SU-AI with TCP/SMTP; 30 Aug 83 14:35:39 PDT
Received: from MIT-MC by USC-ECL; Tue 30 Aug 83 14:30:54-PDT
Date: Tue, 30 Aug 83 13:54 PDT
From: Bobrow.PA@PARC-MAXC.ARPA
Subject: Re: function cells
In-reply-to: "Deutsch's message of Tue, 23 Aug 83 14:13 PDT"
To: Julian Padget <PADGET@UTAH-20.ARPA>
cc: Deutsch.PA@PARC-MAXC.ARPA, lisp-forum@MIT-MC.ARPA,
Bobrow.PA@PARC-MAXC.ARPA, Teitelman.PA@PARC-MAXC.ARPA
I must admit that it was my idea of having separate function cells,
value cells, pname cells, and property lists for Lisp atoms in BBN-Lisp.
I am a believer in separating out mechanisms when there are distinct
differences in function. I think lookup of functions is semantically
different than lookup of variables. The time scale for which bindings
are applicable for variables and fn definitions are applicable are quite
different different in the usual case.
∂30-Aug-83 2109 @USC-ECL:GJC@MIT-MC Function cells.
Received: from USC-ECL by SU-AI with TCP/SMTP; 30 Aug 83 21:09:31 PDT
Received: from MIT-MC by USC-ECL; Tue 30 Aug 83 21:04:04-PDT
Date: 30 August 1983 23:58 EDT
From: George J. Carrette <GJC @ MIT-MC>
Subject: Function cells.
To: LISP-FORUM @ MIT-MC
I would credit JONL with introducing what is effectively the
function-cell functionality to Maclisp. Even though the internals
of the function calling mechanism in maclisp uses various properties,
EXPR, FEXPR, LSUBR, SUBR, FSUBR, and also various function cells with
the UUOLINK mechanism, the user only need be aware of the existence of
DEFUN. Here is some old lisp mail on the topic:
3/1/69 JONL
THE CURRENT VERSION OF LISP, "LISP 102", HAS
THE FOLLOWING AS-YET UNDOCUMENTED FEATURES:
1)"DEFUN" IS AN FSUBR USED TO DEFINE
FUNCTIONS. EXAMPLES ARE
(DEFUN ONECONS (X) (CONS 1 X))
WHICH IS EQUIVALENT TO
(DEFPROP ONECONS
(LAMBDA (X) (CONS 1 X)
EXPR)
THE NOVEL FEATURE OF "DEFUN" IS THAT ONE NEED
NOT BE SO CONCERNED WITH BALANCING
PARENTHESES AT THE VERY END OF THE FUNCTION
DEFINITION. ALSO, THE "LAMBDA" NEED NOT BE
DIRECTLY INSERTED.
Of course, the time this note was written none of the hairier
specialized calling mechanisms had been added to maclisp.
-gjc
∂01-Sep-83 0534 @USC-ECL,@MIT-MC:TIM@MIT-OZ Function cells
Received: from USC-ECL by SU-AI with TCP/SMTP; 1 Sep 83 05:34:20 PDT
Received: from MIT-MC by USC-ECL; Thu 1 Sep 83 05:34:10-PDT
Date: Thu, 1 Sep 1983 07:37 EDT
Message-ID: <[MIT-OZ].TIM. 1-Sep-83 07:37:32>
From: TIM@MIT-OZ
To: Bobrow.PA@PARC-MAXC.ARPA
Cc: Deutsch.PA@PARC-MAXC.ARPA, lisp-forum@MIT-MC.ARPA,
Julian Padget <PADGET@UTAH-20.ARPA>, Teitelman.PA@PARC-MAXC.ARPA
Subject: Function cells
In-reply-to: Msg of 30 Aug 1983 16:54-EDT from Bobrow.PA at PARC-MAXC.ARPA
For the "usual case" it is perfectly reasonable to have separate
function and value cells--I make use of that feature all the time.
But the situation changes when you start to pass functions around in
value cells. The awkward convention of specifying a function call by
(FUNCALL fun arg1 arg2 ...) ;where the function is found in the
;value cell of FUN
rather than
(fun arg1 arg2 ...) ;in the usual case
is perpetuated by having both a function cell and a value cell. In
languages which do not adopt this convention (such as Gerry Sussman
and Guy Steele's Scheme) it is possible to use the latter form in
every case, even when FUN has been passed as an argument. Thus
(define (foo fn a b) ;(The slight difference in the syntax
(fn (* 2 a) b)) ;of FOO's function spec is incidental)
replaces
(defun foo (fn a b)
(funcall fn (* 2 a) b))
I realize that the deep binding scheme in early Lisp implementations
made it necessary to have a separate mechanism for fast function
lookup, and that the namespace limitation of dynamic scoping makes
having a function context and a variable context handy, but I do not
think that the function/value dichotomy should continue into the
lexically scoped Common Lisp. In the case where a variable contains a
function (in its value cell) I see little semantic distinction between
the lookup of variables and functions. In this respect, I fail to see
your point about "separating out mechanisms." I see it justifiable
only for efficiency reasons and for coping with a limited namespace.
Tim McNerney
∂01-Sep-83 1454 @USC-ECL,@MIT-MC:Bobrow.PA@PARC-MAXC Re: Function cells
Received: from USC-ECL by SU-AI with TCP/SMTP; 1 Sep 83 14:54:01 PDT
Received: from MIT-MC by USC-ECL; Thu 1 Sep 83 14:51:40-PDT
Date: Thu, 1 Sep 83 14:30 PDT
From: Bobrow.PA@PARC-MAXC.ARPA
Subject: Re: Function cells
In-reply-to: <[MIT-OZ].TIM. 1-Sep-83 07:37:32>
To: TIM%MIT-OZ@MIT-MC.ARPA
cc: Bobrow.PA@PARC-MAXC.ARPA, Deutsch.PA@PARC-MAXC.ARPA,
lisp-forum@MIT-MC.ARPA, Julian Padget <PADGET@UTAH-20.ARPA>,
Teitelman.PA@PARC-MAXC.ARPA
Tim,
There is a difference in meaning between:
(fun x y) and (FUNCALL fun x y).
In the former case, one expects the meaning of fun to be independent of
the context of the call. In the latter, to be dependent of parameters
passed in to the environment. One can take the point of view that one
doesn't want to distinguish these cases, but I maintain that the code is
clearer when you do make the distinction for the call. Similarly, I
have seen proposals for doing object oriented programming by having the
function name evaluated in the context of the first argument to the
function (which would in fact be a closure on some functions and
variables). I object to that as well.
So for me the question is not about efficiency and limitation of name
space, but of what distinctions you want to make apparent at a call.
danny bobrow
∂01-Sep-83 1549 @USC-ECL,@MIT-MC:BENSON@SPA-NIMBUS Re: Function cells
Received: from USC-ECL by SU-AI with TCP/SMTP; 1 Sep 83 15:49:35 PDT
Received: from MIT-MC by USC-ECL; Thu 1 Sep 83 15:41:07-PDT
Received: from SPA-Nimbus by SPA-Nimbus with CHAOS; Thu 1-Sep-83 15:36:05-PDT
Date: Thursday, 1 September 1983, 15:35-PDT
From: Eric Benson <BENSON at SPA-Nimbus>
Subject: Re: Function cells
To: Bobrow.PA at PARC-MAXC.ARPA, TIM%MIT-OZ at MIT-MC.ARPA
Cc: Deutsch.PA at PARC-MAXC.ARPA, lisp-forum at MIT-MC.ARPA,
Julian Padget <PADGET at UTAH-20.ARPA>,
Teitelman.PA at PARC-MAXC.ARPA
In-reply-to: The message of 1 Sep 83 14:30-PDT from Bobrow.PA at PARC-MAXC.ARPA
Date: Thu, 1 Sep 83 14:30 PDT
From: Bobrow.PA@PARC-MAXC.ARPA
Tim,
There is a difference in meaning between:
(fun x y) and (FUNCALL fun x y).
In the former case, one expects the meaning of fun to be independent of
the context of the call. In the latter, to be dependent of parameters
passed in to the environment. One can take the point of view that one
doesn't want to distinguish these cases, but I maintain that the code is
clearer when you do make the distinction for the call. Similarly, I
have seen proposals for doing object oriented programming by having the
function name evaluated in the context of the first argument to the
function (which would in fact be a closure on some functions and
variables). I object to that as well.
So for me the question is not about efficiency and limitation of name
space, but of what distinctions you want to make apparent at a call.
danny bobrow
By this reasoning you must object to the Common Lisp special forms
LABELS and FLET, which define lexically scoped functions. With the
inclusion of these, function name evaluation is no longer independent of
context. It is only dependent on the static context, however; there is
no dynamic binding of function names in Common Lisp. Is it only
dependence on dynamic context you object to, or dependence on any
context?
∂01-Sep-83 1632 @USC-ECL,@MIT-MC:Deutsch.PA@PARC-MAXC Re: Function cells
Received: from USC-ECL by SU-AI with TCP/SMTP; 1 Sep 83 16:31:50 PDT
Received: from MIT-MC by USC-ECL; Thu 1 Sep 83 16:30:03-PDT
Date: Thu, 1 Sep 83 16:19 PDT
From: Deutsch.PA@PARC-MAXC.ARPA
Subject: Re: Function cells
In-reply-to: "Bobrow's message of Thu, 1 Sep 83 14:30 PDT"
To: Bobrow.PA@PARC-MAXC.ARPA
cc: TIM%MIT-OZ@MIT-MC.ARPA, lisp-forum@MIT-MC.ARPA, Julian Padget
<PADGET@UTAH-20.ARPA>, Teitelman.PA@PARC-MAXC.ARPA
Danny,
I have to side with the Common Lisp / T people on this one. Just
because most (but not all) function invocations use names that are bound
in a global, flat name space (which all modern Lisp systems are finding
ways to enrich), and most (but not all) variables are bound more locally
(in this lexical scope? in a dynamically enclosing but far-from-apparent
scope? in an enclosing lexical scope?), is not enough of a reason for
introducing a mechanism that adds complexity all over the system.
T takes the viewpoint that all identifiers are on a par. The compiler
is able to take advantage of pragmatic information about things being
constant or not dynamically rebound, regardless of whether they are
functions or variables. I imagine Common Lisp is the same.
Function cells seemed like a good idea at the time, just like
GLOBALVARS. I think they were both pragmatic successes and semantic
mistakes.
∂01-Sep-83 1707 @USC-ECL,@MIT-MC:PADGET@UTAH-20 Re: Function cells
Received: from USC-ECL by SU-AI with TCP/SMTP; 1 Sep 83 17:06:12 PDT
Received: from MIT-MC by USC-ECL; Thu 1 Sep 83 16:58:45-PDT
Date: 1 Sep 1983 1746-MDT
From: Julian Padget <PADGET@UTAH-20>
Subject: Re: Function cells
To: BOBROW.PA@PARC-MAXC
cc: Padget@UTAH-20, DEUTSCH.PA@PARC-MAXC, LISP-FORUM@MIT-MC,
TEITELMAN.PA@PARC-MAXC, TIM%MIT-OZ@MIT-MC
In-Reply-To: Your message of 1-Sep-83 1551-MDT
As an aside to the main discussion, I do not condone the use of both
the function and the value cell as a programming style, I am also doubtful
about Tim's appellation of this as a feature.
I should also remark that there are some 'real' LISPs that only provide
one location for keeping a value associated with an id (ie no function cell),
in particular Cambridge LISP.
I would vote with Tim to remove this dichotomy which is being continued in
Common LISP, for reasons which are given in more detail below. However I
strongly suspect that the main reason for its retention in CL is not for
aesthetic but political motives - how else is MACSYMA going to run under CL,
the coding style therein uses this 'feature' quite a lot, and rewriting
all the affected parts is not an overnight job.
I maintain that a function IS a value, and the distinction between value
and function is erroneous. Although no-one would seriously regard LISP as a
faithful implementation of the semantics of lambda calculus, it is not
unreasonable to pay lip service to its (our??) heritage.
With respect to the question of clarity: there is a problem with the
handling of anonymous functions (as in say the MAP functions), and in the
case of high order functions. Although this example may seem somewhat
contrived, it is relevant.
R-Sum and I-sum define functions to do a curried summation (I provide
both for a little variety):
(De R-Sum (a0)
(Function
(Lambda (ai)
(Cond ((Zerop ai) a0) (t (R-Sum (Plus a0 ai)))))))
alternatively:
(De I-Sum (a0)
(Prog (fn)
(Return
(SetQ fn
(Function
(Lambda (ai)
(Cond ((Zerop ai) a0) (t (SetQ a0 (Plus a0 ai))))
fn))))))
now using these in a single cell system gives rise to the following
expression:
(((((I-sum 1) 2) 3) 4) 0)
if FUNCALL must be used this becomes:
(FunCall (FunCall (FunCall (FunCall (I-sum 1) 2) 3) 4) 0)
In addition to being a matter of style/personal taste, it is a
question of consistency (as Peter Deutsch remarked), each element of
a form is treated the same way - even assuming the first element is
evaluated repeatedly until an object which can be applied is found, since
that is simply a recursion in eval without passing the rest of the form
downwards.
--Julian Padget.
-------
∂01-Sep-83 1817 @USC-ECL,@MIT-MC:Bobrow.PA@PARC-MAXC Re: Function cells
Received: from USC-ECL by SU-AI with TCP/SMTP; 1 Sep 83 18:16:40 PDT
Received: from MIT-MC by USC-ECL; Thu 1 Sep 83 18:15:58-PDT
Date: Thu, 1 Sep 83 18:11 PDT
From: Bobrow.PA@PARC-MAXC.ARPA
Subject: Re: Function cells
In-reply-to: "BENSON@SPA-Nimbus.ARPA's message of Thu, 1 Sep 83 15:35
PDT"
To: Eric Benson <BENSON@SPA-Nimbus.ARPA>
cc: Bobrow.PA@PARC-MAXC.ARPA, TIM%MIT-OZ@MIT-MC.ARPA,
Deutsch.PA@PARC-MAXC.ARPA, lisp-forum@MIT-MC.ARPA, Julian Padget
<PADGET@UTAH-20.ARPA>, Teitelman.PA@PARC-MAXC.ARPA
I don't object to definitions which depend on context. I like to see
uses which depend on such context dependent definitions distinguished
from ones which don't.
∂03-Sep-83 1232 @USC-ECL,@MIT-MC:ZVONA@MIT-OZ Function cells
Received: from USC-ECL by SU-AI with TCP/SMTP; 3 Sep 83 12:32:21 PDT
Received: from MIT-MC by USC-ECL; Sat 3 Sep 83 11:50:24-PDT
Date: Sat, 3 Sep 1983 14:38 EDT
Message-ID: <[MIT-OZ].ZVONA. 3-Sep-83 14:38:45>
From: ZVONA@MIT-OZ
To: Bobrow.PA@PARC-MAXC.ARPA
Cc: Eric Benson <BENSON@SPA-Nimbus.ARPA>, Deutsch.PA@PARC-MAXC.ARPA,
lisp-forum@MIT-MC.ARPA, Julian Padget <PADGET@UTAH-20.ARPA>,
Teitelman.PA@PARC-MAXC.ARPA, TIM%MIT-OZ@MIT-MC.ARPA
Subject: Function cells
In-reply-to: Msg of 1 Sep 1983 21:11-EDT from Bobrow.PA at PARC-MAXC.ARPA
The "function spec" problem in Common Lisp is one that makes clear the
advantages of treating "functions and values" uniformly.
It is common to store functions as properties of symbols. This allows
a clean implementation of data-directed dispatching: you write
(funcall (get snabozzle 'quibbix) . args) in order to do a
quibbix-type dispatch on the snabozzle. To support this, you want a
clean way to write the functions that will be stored on the property
list and to get them into the property list. In a lambda calculus
system, you might write
(put 'some-snabozzle 'quibbix (lambda ...))
but modern lisps have defun, which has a lot of useful syntax that
you'd like to use in defining the dispatched-to functions.
Maclisp provided the syntax
(defun (some-snabozzle quibbix) arglist . body)
which would effectively macroexpand into the same thing (and also hack
defun-syntax and process declarations and so forth for you). This
syntax had a number of problems; among them, especially, that besides
the "function cell" and properties there are other places that you
might want to store functions. Therefore, lisp machine lisp did an
almost-upward-compatible extension to this in which the defun name
(first subform) if a list would dispatch on the car of the list if
possible. The car of the list could then be a keyword that would tell
where to put the function.
(defun (:property some-snabozzle quibbix) arglist . body)
for example. These lists (such as (:property ...)) were called
"function specs". The lisp machine provides for each function spec a
set of things that can be done to it: you can define it, undefine it
(make it unbound), get its definition, and so on.
All this amounts to a fair amount of conceptual overhead (though to
total amount of code to implement it fits in a few pages). It is no
longer obvious just what it is that defun abstractly macroexpands
into; it is doing some magic with the function specs behind your back.
Moreover, it is often unclear in what contexts it is allowable to use
a function spec. For example, beginners who are first introduced to
function specs often try to write
((:property snabozzle quibbix) . args)
or
(funcall (:property snabozzle quibbix) . args)
This suggests that perhaps what one ought to be writing is
(defun (get 'some-snabozzle 'quibbix) arglist . body)
because it is intuitively clearer if the defining and using forms have
the same syntax. Moreover, this eliminates all the overhead of
function specs. And then defun again has a clear macroexpansion: it
is really just sugar for setf! That is, the defun above is really
(setf (get 'some-snabozzle 'quibbix) (lambda arglist . body))
There is just one difficulty with this: what does
(defun drofnats (self) (capitalize (string-reverse self)))
macroexpand into? It ought to be
(setf drofnats (lambda (self) (capitalize (string-reverse self))))
but that sets the value cell, not the function cell!
This, finally, is the point: The elegant setf syntax for defun was
abandoned for common lisp because it didn't "work" on symbols. The
true story is that the uniform handling of functions as values is a
self-consistent system, and function cells are a confused mess.
*** *** *** ***
It is worth mentioning that (function ...) is intimately tied up with
the function cell lossage. Common lisp weirdly chose to implement
lambda right, but to require a no-op #' in front of it. (Anyone who
wants to win, of course, can define lambda as a macro that expands
into #'(lambda ...). Takes all kinds.)
*** *** *** ***
Common lisp people:
defun setf syntax seems like such a win that perhaps it could be
salvaged by the following klduge (which seems better than function
specs):
defun has setf-syntax except on symbols. It uses the function cell
with symbols. You can set the value cell of a symbol with
(defun (symbol-value symbol) ...)
∂03-Sep-83 1833 @USC-ECL,@MIT-MC:RWK@SCRC-TENEX Function cells
Received: from USC-ECL by SU-AI with TCP/SMTP; 3 Sep 83 18:30:54 PDT
Received: from MIT-MC by USC-ECL; Sat 3 Sep 83 18:28:19-PDT
Received: from SCRC-YUKON by SCRC-TENEX with CHAOS; Sat 3-Sep-83 21:12:55-EDT
Date: Saturday, 3 September 1983, 21:06-EDT
From: Robert W. Kerns <RWK at SCRC>
Subject: Function cells
To: ZVONA at OZ, Bobrow.PA at PARC-MAXC
Cc: BENSON at SPA-Nimbus.ARPA, Deutsch.PA at PARC-MAXC, lisp-forum at MC,
PADGET at UTAH-20, Teitelman.PA at PARC-MAXC, TIM%MIT-OZ at MC
In-reply-to: <[MIT-OZ].ZVONA. 3-Sep-83 14:38:45>
Date: Sat, 3 Sep 1983 14:38 EDT
From: ZVONA@MIT-OZ
The "function spec" problem in Common Lisp is one that makes clear the
advantages of treating "functions and values" uniformly.
It is common to store functions as properties of symbols. This allows
a clean implementation of data-directed dispatching: you write
(funcall (get snabozzle 'quibbix) . args) in order to do a
quibbix-type dispatch on the snabozzle. To support this, you want a
clean way to write the functions that will be stored on the property
list and to get them into the property list. In a lambda calculus
system, you might write
(put 'some-snabozzle 'quibbix (lambda ...))
but modern lisps have defun, which has a lot of useful syntax that
you'd like to use in defining the dispatched-to functions.
Maclisp provided the syntax
(defun (some-snabozzle quibbix) arglist . body)
which would effectively macroexpand into the same thing (and also hack
defun-syntax and process declarations and so forth for you). This
syntax had a number of problems; among them, especially, that besides
the "function cell" and properties there are other places that you
might want to store functions. Therefore, lisp machine lisp did an
almost-upward-compatible extension to this in which the defun name
(first subform) if a list would dispatch on the car of the list if
possible. The car of the list could then be a keyword that would tell
where to put the function.
(defun (:property some-snabozzle quibbix) arglist . body)
for example. These lists (such as (:property ...)) were called
"function specs". The lisp machine provides for each function spec a
set of things that can be done to it: you can define it, undefine it
(make it unbound), get its definition, and so on.
All this amounts to a fair amount of conceptual overhead (though to
total amount of code to implement it fits in a few pages). It is no
longer obvious just what it is that defun abstractly macroexpands
into; it is doing some magic with the function specs behind your back.
Moreover, it is often unclear in what contexts it is allowable to use
a function spec. For example, beginners who are first introduced to
function specs often try to write
((:property snabozzle quibbix) . args)
or
(funcall (:property snabozzle quibbix) . args)
This suggests that perhaps what one ought to be writing is
(defun (get 'some-snabozzle 'quibbix) arglist . body)
No, one should write (funcall #'(:property snaboozle quibbix) . args)
just like one should write (funcall #'snaboozle . args) or
(funcall #'(lambda (x) (+ x x)) . args). The non-uniformity
here is that (funcall 'snaboozle . args) or
(funcall '(lambda (x) (+ x x)) . args) will work at all.
The only problem with writing ((:property snabozzle quibbix) . args)
is that it is visually confusing. You can't argue that because
((:property snabozzle quibbix) . args) doesn't work that the
idea of a function spec is inelegant! At most you can say that
a piece of it that should work doesn't.
because it is intuitively clearer if the defining and using forms have
the same syntax. Moreover, this eliminates all the overhead of
function specs. And then defun again has a clear macroexpansion: it
is really just sugar for setf!
Bullshit. DEFUN started out life as sugar for DEFPROP, not PUTPROP.
The difference is that the compiler was then considered free to compile
things defined with DEFPROP. In more modern times, the compiler is
considered free to compile things "quoted" with FUNCTION rather than
QUOTE. So...
That is, the defun above is really
(setf (get 'some-snabozzle 'quibbix) (lambda arglist . body))
There is just one difficulty with this: what does
(defun drofnats (self) (capitalize (string-reverse self)))
macroexpand into? It ought to be
(setf drofnats (lambda (self) (capitalize (string-reverse self))))
but that sets the value cell, not the function cell!
In the current scheme,
(DEFUN FOO (X) (BAR X)) ==>
(SETF #'FOO #'(LAMBDA (X) (BAR X)))
(DEFUN (:PROPERTY FOO :FUN-PROP) (X) (BAR X)) ==>
(SETF #'(:PROPERTY FOO :FUN-PROP) #'(LAMBDA (X) (BAR X)))
This, finally, is the point: The elegant setf syntax for defun was
abandoned for common lisp because it didn't "work" on symbols. The
true story is that the uniform handling of functions as values is a
self-consistent system, and function cells are a confused mess.
That is indeed the problem with your scheme, it turns function cells
into a confused mess. It also ignores every shred of consistancy in
favor of your own internal confusion. Proof by Solipsism is not
acceptable.
*** *** *** ***
It is worth mentioning that (function ...) is intimately tied up with
the function cell lossage. Common lisp weirdly chose to implement
lambda right, but to require a no-op #' in front of it. (Anyone who
wants to win, of course, can define lambda as a macro that expands
into #'(lambda ...). Takes all kinds.)
You're right, it is connected. You can view (FUNCTION ...) as meaning
"do what you do to the CAR of a combination to get the function to be
performed". It doesn't buy you much to say that what you do with
the FIRST of a form should be the same as what you do the the SECOND.
It just isn't true after you get your hands on the function, especially
in the case of macros.
The distinction here is very much like the distinction between nouns
and verbs in English. Frequently a word is both a noun and a verb,
but the distinction is clear from context. For example, LIST is both
a noun and a verb. I have seen many users of lisps without function
cells SCREW THEMSELVES TO THE WALL by using something as a temporary
variable that happens to also be a function name. LIST is the most
common offender. (This is made worse by lisps which defaultly use
dynamic scoping, but people also have screwed themselves doing
(SETQ LIST (GET-ITEM-LIST 'FOO)) at top level).
*** *** *** ***
Common lisp people:
defun setf syntax seems like such a win that perhaps it could be
salvaged by the following klduge (which seems better than function
specs):
defun has setf-syntax except on symbols. It uses the function cell
with symbols. You can set the value cell of a symbol with
(defun (symbol-value symbol) ...)
ARGH! This does nobody any favors. It is every bit as bad as you
imagine distinguishing between functions and values is.
This debate really annoys me, partly because not a single new thing has
been said (with the exception of your SETF/DEFUN scheme, which I detest).
Most of the people involved with Common Lisp have faced this issue and
been thinking about it for 5 years or more. Most of the arguments against
it are based on an unstated assumption that saying (FUNCALL X ...) is
an unwanted complexity rather than a helpful clarification, or that
the slight simplification of eliminating the function cell is worth
sacraficing the clarity, or that the slight simplification of calling
EVAL on the CAR of the form is worth anything at all.
What I don't understand is why everybody goes on about the FUNCTION cell
in favor of the VALUE cell. Why isn't anybody proposing we do away with
the VALUE cell. The history of the VALUE cell in MacLisp *IS THE SAME
AS THAT OF THE FUNCTION CELL*. I.e. they both used to simply be
properties on the property list. The evaluator would do a (GET SYMBOL
'VALUE), just like it would do a (GET SYMBOL 'EXPR). It is obvious that
these are both properties of a symbol, just like (GET SYMBOL 'SI:FLAVOR)
is.
Really, let's not go half-way. Let's take the argument for merging the
VALUE and FUNCTION properties to its logical extreme, and eliminate the
property-list altogether!
Personally, I'd rather keep distinct meanings separate (noun-meaning
(value), verb-meaning (function), adjective-meaning (flavor)), and try
to have the most EXPRESSIVE language, not the SIMPLEST language.
∂05-Sep-83 1235 @USC-ECL,@MIT-MC:Moon@SCRC-TENEX Function cells
Received: from USC-ECL by SU-AI with TCP/SMTP; 5 Sep 83 12:35:29 PDT
Received: from MIT-MC by USC-ECL; Mon 5 Sep 83 12:05:35-PDT
Received: from scrc-schuylkill by scrc-cupid with CHAOS; 5 Sep 1983 14:45:22-EDT
Date: Monday, 5 September 1983, 14:52-EDT
From: David A. Moon <Moon at SCRC>
Subject: Function cells
To: ZVONA at OZ, RWK at SCRC, BENSON at NIMBUS, Bobrow.PA at PARC-MAXC,
Deutsch.PA at PARC-MAXC, PADGET at UTAH-20,
Teitelman.PA at PARC-MAXC, TIM at OZ
Cc: lisp-forum at MC
Could the people who are interested in this "function cells" discussion
please move it to another mailing list, where I don't have to see it?
If other people on Lisp-forum feel that the discussion should continue
on Lisp-forum, please send mail to me directly and if enough people
so believe I will remove myself from lisp-forum.
∂05-Sep-83 1325 @USC-ECL,@MIT-MC:jkf%ucbkim@Berkeley Re: Function cells
Received: from USC-ECL by SU-AI with TCP/SMTP; 5 Sep 83 13:25:23 PDT
Received: from MIT-MC by USC-ECL; Mon 5 Sep 83 13:24:39-PDT
Received: from ucbkim.ARPA by ucbvax.ARPA (4.9/4.7)
id AA12745; Mon, 5 Sep 83 13:21:08 PDT
Received: by ucbkim.ARPA (4.6/4.2)
id AA15598; Mon, 5 Sep 83 13:20:31 PDT
Date: Mon, 5 Sep 83 13:20:31 PDT
From: jkf%ucbkim@Berkeley (John Foderaro)
Message-Id: <8309052020.AA15598@ucbkim.ARPA>
To: Moon@SCRC
Subject: Re: Function cells
Cc: lisp-forum@MC
In-Reply-To: Your message of Monday, 5 September 1983, 14:52-EDT
While I am not particularly interested in the discussion on function cells,
I think that lisp-forum is the precise place to have such a discussion for
those who are interested.
I've never understood why so many people insist on stifiling discussions on
mailing lists. I can only conclude that there are a lot of crufty mail
reading programs out there that force you to read every character of every
letter you receive.
∂05-Sep-83 1347 @USC-ECL,@MIT-MC:ZVONA@MIT-OZ Function cells
Received: from USC-ECL by SU-AI with TCP/SMTP; 5 Sep 83 13:46:26 PDT
Received: from MIT-MC by USC-ECL; Mon 5 Sep 83 11:11:10-PDT
Date: Mon, 5 Sep 1983 13:41 EDT
Message-ID: <[MIT-OZ].ZVONA. 5-Sep-83 13:41:00>
From: ZVONA@MIT-OZ
To: Robert W. Kerns <RWK@SCRC-TENEX>
Cc: BENSON@SPA-Nimbus.ARPA, Bobrow.PA@PARC-MAXC, Deutsch.PA@PARC-MAXC,
lisp-forum@MIT-MC, PADGET@UTAH-20, Teitelman.PA@PARC-MAXC,
TIM%MIT-OZ@MIT-MC
Subject: Function cells
In-reply-to: Msg of 3 Sep 1983 21:06-EDT from Robert W. Kerns <RWK at SCRC>
Well. There are probably people who can argue this better, but none
have stepped forward, so...
What I don't understand is why everybody goes on about the FUNCTION cell
in favor of the VALUE cell. Why isn't anybody proposing we do away with
the VALUE cell. The history of the VALUE cell in MacLisp *IS THE SAME
AS THAT OF THE FUNCTION CELL*. Really, let's not go half-way.
Let's take the argument for merging the VALUE and FUNCTION
properties to its logical extreme, and eliminate the property-list
altogether!
I think that is a good idea. (This step was seriously discussed in
the design of T.) The whole idea of symbols is overloaded and
bankrupt. The different uses and features of symbols ought to be
separated out. First, there is the idea of INTERNED STRINGS, a useful
user-interface feature. So we'll have such a datatype. Then there is
the separate idea of NAMES: any object can name another; to an object,
you can associate a value and retrieve it efficiently. (T lets you
associate a value with any S-expression.) Quite another idea is that
of PROPERTIES; Brand-X and (I think) MIT-scheme allow any object to
have properties associated with it; there is nothing special about
``symbols''. I never use properties, myself; I think that they are
almost always an artifact of unclear thought, and that you'd do better
to use something else. The main uses are in user interface, when a
user uses a symbol to name a structure, in which case you'd do better
to use a hashtable that maps symbols to their associated structure;
and in storing random crufties, in which case you should probably be
using DEFSTRUCT.
Unfortunately, naming is currently all mixed up with EVAL, which is
pretty much bankrupt itself. The reason that currently symbols have
values and not other things is that the main thing that gets values is
EVAL, and other things mean something special to EVAL. So lists, for
example, will not have their values used much, and from what I can
see, T makes no use of the extended variable feature.
Brian Smith's thesis straightens this particular mess out by replacing
EVAL with two things: NORMALIZE, and DOWN-ARROW. DOWN-ARROW gets the
``value'' of something: the thing that is designated by its argument.
NORMALIZE simplifies expressions. If you want to understand what
QUOTE is really for, and how naming should work, you should read his
thesis (it's an LCS TR). But his 2-LISP is probably too outre' to
discuss on this mailing list.
... You can view (FUNCTION ...) as meaning
"do what you do to the CAR of a combination to get the function to be
performed". It doesn't buy you much to say that what you do with
the FIRST of a form should be the same as what you do the the SECOND.
It just isn't true after you get your hands on the function, especially
in the case of macros.
Your point here (which must be the crux of your argument) is not quite
clear to me. Obviously the car of all forms can not be treated the
same way as the other subforms; but in the case of special forms such
as SETQ, various non-car subforms are treated in different ways
anyway. The issue is meaningful only for forms that are simple
combinations, i.e. function applications. [FUNCTION of a symbol that
refers to a macro returns something completely random on the lisp
machine, anyway. What does your last sentence mean?] The fact is
that even for simple combinations, the CAR is treated specially, since
it is the one that is applied to all the others. The claim is not
that the uniformity of handling at this level is especially winning.
The uniformity really arises from the fact that there is only one
thing going on here, and that is NAMING. And the names of functions
are no different from the names of anything else.
I have seen many users of lisps without function
cells SCREW THEMSELVES TO THE WALL by using something as a temporary
variable that happens to also be a function name. LIST is the most
common offender. (This is made worse by lisps which defaultly use
dynamic scoping, but people also have screwed themselves doing
(SETQ LIST (GET-ITEM-LIST 'FOO)) at top level).
There are lots of ways to screw yourself when you are first learning
Lisp. (Try tracing PRINT.) In a language that is lexically scoped
and in which the system functions are locked and sacred (as, I
believe, they are in MIT scheme) the danger is much reduced, and not
worth making the language counter-intuitive over.
because it is intuitively clearer if the defining and using forms have
the same syntax. Moreover, this eliminates all the overhead of
function specs. And then defun again has a clear macroexpansion: it
is really just sugar for setf!
Bullshit. DEFUN started out life as sugar for DEFPROP, not PUTPROP.
The difference is that the compiler was then considered free to compile
things defined with DEFPROP. In more modern times, the compiler is
considered free to compile things "quoted" with FUNCTION rather than
QUOTE. So...
In an ideal world (which is not even particularly hard to achieve --
the MIT scheme implementation, at least, succeeds) there should be no
difference between code to be compiled and code to be interpreted
(except for declarations that will allow the compiler to optimize code
without changing the semantics). It should never be necessary for the
user to reason about differences between the behaviors of his program
compiled and interpreted. Any sort of ``compilable contexts'' kludge
such as #', special handling of DEFPROP, and (PROGN 'COMPILE ...)
makes it much less clear what the compiler is doing, and harder to
think about how to write code.
You can't argue that because
((:property snabozzle quibbix) . args) doesn't work that the
idea of a function spec is inelegant! At most you can say that
a piece of it that should work doesn't.
Certainly it would be an incremental improvement if this worked.
In the current scheme,
(DEFUN (:PROPERTY FOO :FUN-PROP) (X) (BAR X)) ==>
(SETF #'(:PROPERTY FOO :FUN-PROP) #'(LAMBDA (X) (BAR X)))
This doesn't work currently on the lisp machine. Presumably it does
in the incomplete Common Lisp function spec proposal.
(defun (symbol-value symbol) ...)
ARGH! This does nobody any favors. It is every bit as bad as you
imagine distinguishing between functions and values is.
OK, fair enough, this sucked.
Most of the people involved with Common Lisp have faced this issue and
been thinking about it for 5 years or more.
So have the Scheme people; so have I, for that matter. [Disclaimer: I
do not work on any brand of Scheme, and am quite skeptical of all
existing implementations. I use lisp machines, which are clearly a
vastly superior programming system, even though the Lisp they are
based on is a little crufty.]
Most of the arguments against [function cells] are based on an
unstated assumption that saying (FUNCALL X ...) is
an unwanted complexity rather than a helpful clarification, or that
the slight simplification of eliminating the function cell is worth
sacraficing the clarity, or that the slight simplification of calling
EVAL on the CAR of the form is worth anything at all.
These assumptions aren't really unstated; they are firm convictions of
many people. Some people that have programmed in languages both with
and without funtion cells find those without to be much clearer; no
sacrifice is involved.
∂05-Sep-83 1625 @USC-ECL:GJC@MIT-MC Zippy the mailer, or ... are we on the net yet?
Received: from USC-ECL by SU-AI with TCP/SMTP; 5 Sep 83 16:25:29 PDT
Received: from MIT-MC by USC-ECL; Mon 5 Sep 83 16:25:30-PDT
Date: 5 September 1983 19:15 EDT
From: George J. Carrette <GJC @ MIT-MC>
Subject: Zippy the mailer, or ... are we on the net yet?
To: jkf @ UCBKIM
cc: LISP-FORUM @ MIT-MC, Moon @ SCRC-TENEX
In-reply-to: Msg of Mon 5 Sep 83 13:20:31 PDT from jkf%ucbkim at Berkeley (John Foderaro)
Really now. In all probability Dave Moon is reading his mail on his
own personal lisp machine which has about as much or more physical memory and
speed as your usual DEC-20 or VAX-11/780 installation for 50 users, so it just
doesn't make much sense in this case to be making snide comments about
poor quality mail reading programs in the context of stifiling
discussions on mailing lists.
Given that bit of information, maybe you can just take Daves very polite
comment at face value.
-gjc
∂06-Sep-83 1759 @USC-ECL,@MIT-MC:PADGET@UTAH-20 Re: Function cells
Received: from USC-ECL by SU-AI with TCP/SMTP; 6 Sep 83 17:58:47 PDT
Received: from MIT-MC by USC-ECL; Tue 6 Sep 83 17:54:14-PDT
Date: 6 Sep 1983 1844-MDT
From: Julian Padget <PADGET@UTAH-20>
Subject: Re: Function cells
To: Moon@SCRC-TENEX, lisp-forum@MIT-MC
cc: Padget@UTAH-20
In-Reply-To: Your message of 5-Sep-83 1304-MDT
Since it was I who initiated this discussion, I feel it behoves me
to reply to Dave Moon.
For the most part the messages on the subject of function cells have
been concise and factual. I do not wish to slander anybody but 'flaming'
only became a problem when some people from MIT joined. The message length
problem has been exacerbated by the popularity of inserting ones own
comments into a message to construct a reply. An alternative is a few
minutes with a pencil and paper, and serves to clarify the mind wonderfully.
The subject matter seems entirely suited to lisp-forum; one cannot
always expect everything in such a digest to be of interest to everyone,
thus I find your reaction surprising and somewhat churlish.
I hope you take these remarks in the spirit in which they are intended.
--Julian Padget.
-------
∂06-Sep-83 1814 @USC-ECL:KMP@MIT-MC
Received: from USC-ECL by SU-AI with TCP/SMTP; 6 Sep 83 18:14:00 PDT
Received: from MIT-MC by USC-ECL; Tue 6 Sep 83 18:10:35-PDT
Date: 6 September 1983 19:17 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
To: DCP @ MIT-MC
cc: RWK @ MIT-MC, ALAN @ MIT-MC, BUG-MACLISP @ MIT-MC, GJC @ MIT-MC,
GUMBY @ MIT-MC
Uh, I believe the story is...
WHEN and UNLESS are in UMLMAC.
They have been there for ages; since long before the LispM adopted them.
It took forever to convince the LispM people that they were a win because
there was a stubbornness on the part of the LispM designers who claimed
that there were already too many control constructs in LispM lisp and that
people should use AND and OR for simple cases and IF/COND for the hairier
cases.
I believe the justification for them being in UMLMAC and not being autoloading
stemmed from the fact that no one was willing to standardize them into
the LispM. I think that now that they have gained acceptance in the LispM
community that it would be an extremely good idea if they became standard
in Maclisp as well.
It seems that my manual doesn't document them, even as something you could
make autoload. That's a bit sad.
∂06-Sep-83 1814 @USC-ECL:DCP@MIT-MC
Received: from USC-ECL by SU-AI with TCP/SMTP; 6 Sep 83 18:14:29 PDT
Received: from MIT-MC by USC-ECL; Tue 6 Sep 83 18:11:06-PDT
Date: 6 September 1983 20:30 EDT
From: David C. Plummer <DCP @ MIT-MC>
To: KMP @ MIT-MC
cc: DCP @ MIT-MC, RWK @ MIT-MC, ALAN @ MIT-MC, BUG-MACLISP @ MIT-MC,
GJC @ MIT-MC, GUMBY @ MIT-MC
Date: 6 September 1983 19:17 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
GUMBY @ MIT-MC
Uh, I believe the story is...
WHEN and UNLESS are in UMLMAC.
...
Yow!! Information and historical perspective! I think we're all
agreed that they should appear in the standard MacLisp, and Alan
mumbled "some day..." which I hope means the next time he has a
hack attack and builds a new MacLisp.
∂17-Sep-83 1709 @USC-ECL:RIVIN@MIT-MC
Received: from USC-ECL by SU-AI with TCP/SMTP; 17 Sep 83 17:09:11 PDT
Received: from MIT-MC by USC-ECL; Sat 17 Sep 83 17:08:57-PDT
Date: 17 September 1983 20:08 EDT
From: Igor Rivin <RIVIN @ MIT-MC>
To: BUG-MACLISP @ MIT-MC
Calling GRIND0 on a file which contains the form
(defun foo (l) (mapcar #'list l))
causes a ;BKPT *RSET-TRAP probably because of the # reader macro.
∂17-Sep-83 1859 @USC-ECL,@MIT-MC:GLR@MIT-OZ SETSYNTAX and (STATUS CHTRAN) on TOPS-20
Received: from USC-ECL by SU-AI with TCP/SMTP; 17 Sep 83 18:59:00 PDT
Received: from MIT-MC by USC-ECL; Sat 17 Sep 83 18:55:17-PDT
Date: Sat, 17 Sep 1983 21:53 EDT
Message-ID: <[MIT-OZ].GLR.17-Sep-83 21:53:22>
From: Jerry Roylance <GLR@MIT-OZ>
To: BUG-LISP@MIT-OZ
Subject: SETSYNTAX and (STATUS CHTRAN) on TOPS-20
;;; Bug in MACLISP
;;; setsyntax screws chtran
;;;
(defun maclisp-bug ()
(let ((readtable (*array nil 'readtable)))
(setsyntax #/, 'single nil)
(print (status macro #/,))
(print (status chtran #/,))
(sstatus macro #/, nil)
(print (status chtran #/,))
NIL
))
I suspect that setsyntax does completely remove the , readmacro.
∂21-Sep-83 2258 @USC-ECL,@MIT-MC:kmp@MIT-MC TYIPEEK and SFAs -- A longstanding bug that needs fixing
Received: from USC-ECL by SU-AI with TCP/SMTP; 21 Sep 83 22:58:32 PDT
Received: from MIT-MC by USC-ECL; Wed 21 Sep 83 22:55:14-PDT
Date: Thursday, 22 September 1983, 01:52-EDT
From: Kent M. Pitman <kmp at MIT-MC>
Subject: TYIPEEK and SFAs -- A longstanding bug that needs fixing
To: Alan at MC
Cc: BUG-MACLISP at MIT-MC
I got mail from you a couple months ago saying you wanted to flush
Maclisp 1914 from MC but I was locking the dump with my Fortran
translator. I finally found the bug report which describes the
reason the translator doesn't run in a later version of Lisp. I'd
appreciate it if you could look at this bug, as I do consider it
rather severe... I just checked and all the reported symptoms still
occur as described in Lisp 2138 on MC.
-----Begin Dredged Up Mail-----
Date: 20 May 1981 04:23-EDT
From: Kent M. Pitman <KMP>
To: BUG-MACLISP
Re: TYIPEEK / SFA interaction changed??
It used to be that the following definition
(DEFUN SFA-HANDLER (SELF OP DATA)
(CASEQ OP ((WHICH-OPERATIONS) '(TYIPEEK))
((TYIPEEK) DATA)
(T (ERROR "I am too dumb to do that" OP))))
(SETQ STREAM (SFA-CREATE #'SFA-HANDLER 0. "Dumb Stream"))
would allow you to do
(TYIPEEK NIL STREAM) => -1
(TYIPEEK NIL STREAM -1) => -1
(TYIPEEK NIL STREAM -3) => -3
even tho
(TYIPEEK NIL (OPEN 'NUL: 'IN) -1) => -1
(TYIPEEK NIL (OPEN 'NUL: 'IN) -3) => -1 ; this was a bug then and still is now
Anyway, now you get the following behavior instead:
(TYIPEEK NIL STREAM) => ;NIL NON-FIXNUM VALUE
(TYIPEEK NIL STREAM -1) => ;NIL NON-FIXNUM VALUE
In an EOF case, the TYIPEEK message to an SFA must be able to return its DATA
argument. DATA used to get bound to #nnnnnn and somehow if you returned this,
it magically figured out you wanted the eof value returned to the user. Now I
would prefer that DATA be bound to the value supplied (default -1 if
none supplied), but that's just preference. The important thing tho' is that
I have code that is broken until someone fixes the TYIPEEK message to pass
some piece of data which if returned will give the right value back from
TYIPEEK without erring...
Naturally, while you're at it you could fix that other bug wherein only -1
can be returned from an EOF on a real file object when TYIPEEK'ing, even if
some other arg is supplied (see the -3 case above).
-kmp
Date: 21 May 1981 02:13-EDT
From: Alias for KMP <TURNIP>
To: BUG-MACLISP
Re: more on yesterday's TYIPEEK lossage
INCST3: TLNE T,SO.TIP ;FOO! TYIPEEK IS DIFFERENT!
TDZA C,C ; BUT IF NOT TYIPEEK THEN USE
MOVEI C,INCST3 ; NEW EOF VALUE, SOMETHING UNIQUE
PUSHJ P,ISTCAL ;CALL THE SFA
POP P,C ;RESTORE EOF VALUE
CAIN A,INCST3 ;DID THE SFA RETURN EOF?
JRST INCST4 ;YES, HANDLE IT
JSP T,FXNV1 ;ELSE THE VALUE RETURNED MUST BE A FIXNUM
POPJ P,
-----
Note how SFA's get sent a NIL but on return check for INCST3 ...? How is
the guy going to know to return that? I just did
(SETQ STREAM (SFA-CREATE #'(LAMBDA (SELF OP DATA)
(CASEQ OP
((WHICH-OPERATIONS) '(TYIPEEK))
((TYIPEEK) '#,(MUNKAM (GETDDTSYM 'INCST3)))
(T (ERROR "Loss" OP))))
0. "Loss"))
(TYIPEEK NIL STREAM) => -1.
(TYIPEEK NIL STREAM -3) => -3.
which is the kind of behavior that I want... Somehow this need for
#,(MUNKAM ...) seems awkward, though.
∂27-Sep-83 1631 @USC-ECL,@MIT-MC:JonL.pa@PARC-MAXC Function Cells -- the history
Received: from USC-ECL by SU-AI with TCP/SMTP; 27 Sep 83 16:28:57 PDT
Received: from MIT-MC by USC-ECL; Tue 27 Sep 83 16:26:45-PDT
Date: Tue, 27 Sep 83 16:16 PDT
From: JonL.pa@PARC-MAXC.ARPA
Subject: Function Cells -- the history
To: Padget@Utah-20.ARPA
cc: Lisp-Forum@MIT-MC.ARPA
There are two parts to your question:
1) who first converted atoms (i.e. LITATOMs or SYMBOLs) from list
structure with weird pointer in the first CAR, to standard block
record structure, and
2) who first differentiated between function context and argument
context when interpreting an atom.
No doubt, there is an element of "why" in your question too.
RE point 1:
Peter Deutsch's answer is quite correct as far as I know -- BBN Lisp
(predecessor to InterLisp) in mid 1960's. The arguments I heard in
later years for justification had more to do with paging behaviour
of compiled code rather than any other. It was *not* (emphasize!) for
the purpose of implementing point 2.
Interestingly, VAX/NIL had a modified "structure" for SYMBOLs; it had
been noted in MACSYMA that big systems could easily contain 2000 or
more symbols, only a small fraction of which utilised both the function
cell and the value cell. So for space saving a kludge was perpetrated in
which every symbol had one cell which was a pointer to either a function
cell, or a value cell, or a more standard block record of all requisite cells.
The reason this was "space saving" was that the implementation of
Local-vs-Dynamic and Function-vs-Value are independent, and thus in
fullness, one needs 4 (four!) value cells. Speed of access isn't an issue,
since compiled code normally links thru the value cell itself (or function
cell, if you must) rather than thru the symbol header; also, the extra cost
for this "hair" is verry small in terms of VAX instructions.
RE point 2:
Did any of the replies to you so far note that this differentiation was
part of Lisp1.5.? See page 18 of the "LISP 1.5 Programmer's Manual" where
the classic scheme is described. I did not "invent" this scheme. Neither
did MacLisp, nor its predecessor PDP6 Lisp, originate it. It was inherited
directly from Lisp 1.5 and CTSS Lisp [remember CTSS? the "Compatible Time
Sharing System" on a greatly modified IBM 7090? Most of the Lisp world
remembers only ITS -- "Incompatible Timesharing System" -- and now it too
is passing away. Sic Transit Gloria Mundi (sic)]
I venture the opinion that the underlying reason why "uniform" treatment
of identifiers is ever thought to be desirable is that it somewhat simplifies
the coding and conceptual complexity of the interpreter/system. There is a
strong series of arguments *against* this "optimisation", made by users of
said systems. Dan Bobrow offered the most compelling of these in his
answer: essentially stated, there is a general expectation that the function
name space is global, unless otherwise stated, and that the variable name
space is local, unless otherwise stated. Once this distinction is admitted,
there is little point in trying to force both meanings into a single "value"
cell -- the conceptual simplicity has been forfeited, and since "function
cell" and "value cell" machinery are isomorphic, there is virtually no
coding advantage remaining.
FUNCALL/APPLY* have been around "since antiquity" to make the exceptions
for function syntax, but VAX/NIL and current CommonLisp permit local
re-binding of function cells *** as an option; The Bobrow "general
expectation" is not violated in these systems. More recently, (i.e., post-1977)
there have been introduced declarations and/or constructs into Interlisp,
LispMachineLisp, VAX/NIL, and CommonLisp to supply the second exception
noted above, namely symbolic constants.
I have frequently offered the observation that this distinction is also
rooted in mathematical notation, where journals generally distinguish
function names from variable names by any of a number of devices:
such as, slant type-face vs perpendicular, boldface versus regular, or
conventional subsets of letters (e.g., "f" and "G" are clearly function
names, whereas "x" and "Y" are variable names). Curiously, I've heard
that there is a reversal of some of these conventions between the American
and the European publishers. Can anyone verify this?)
There seems also to be some confusion about the implementation status of
this "distinction", that variables are by default local. As far as I know,
this *is* true of all major Lisp implementations I've worked with. What
isn't true is that that the interpreters of said systems "do the right thing"
(as opposed to the compiled code environment, which defines the semantics).
Almost without exception, the interpreters implement **only** fluid
bindings. VAX/NIL had an interpreter that correctly implemented both
local and fluid variables (see my paper in the 1982 Lisp Conference for a
description of a non-consing scheme to do it). Many toy interpreters have
been built which implement distinctions, but do so by consing up the usual
old alist environment, or some equivalent thereof. Another interesting
interpreter which implements local variables was done prior to 1977 by the
group at IBM Research Center in Yorktown Heights (in Lisp/370), in which
the interpretation of a lambda application did a mini-compilation in order to
get *exactly* the same stack frame as would be built had the code been truly
compiled; the claim was that you wouldn't see differences between compiled
and interpreted code in Lisp/370.
More in defense of my conjecture above.:
Bobrow tells me that the first implementation of 940Lisp (the "root
stock" of BBN lisp) was with the function/variable "optimisation"
mentioned above. On a small computer, cramped for space, with
a one-man implementation team . . . but the user community
balked, and convinced the implementor to re-support the
mathmatically grounded distinction between function context
and value context. Major Lisp systems today have long passsed
the point where they are one-man projects, but happily haven't
reached OS syndrome yet (i.e., a system so big, with so many ad-hoc
extensions and patches, that no one even knows a complete subset
of people who collectively understand the system).
Several of the SCHEME-lovers have privately expressed the opinion to me
that the value of SCHEME is that it doesn't have a user community (except
for learners and tinkers), and thus *can* be kept super-simple and "clean".
David Warren, a principle implementor of PROLOG, also expressed (privately)
such an opinion, and will rue the day that the Japanese turn Prolog into
some kind operating system for 5th Generation hardware.
There will always be difference of viewpoint between those who want to
"muck around" with program semantics and small, "clean" systems, and
those who want a full complement of "power tools" for doing AI research
and applications program development.
∂27-Sep-83 1716 @USC-ECL:GJC@MIT-MC your note on Function Cells.
Received: from USC-ECL by SU-AI with TCP/SMTP; 27 Sep 83 17:15:18 PDT
Received: from MIT-MC by USC-ECL; Tue 27 Sep 83 17:13:28-PDT
Date: 27 September 1983 20:10 EDT
From: George J. Carrette <GJC @ MIT-MC>
Subject: your note on Function Cells.
To: JonL.pa @ PARC-MAXC
cc: LISP-FORUM @ MIT-MC, Padget @ UTAH-20
In-reply-to: Msg of Tue 27 Sep 83 16:16 PDT from JonL.pa at PARC-MAXC.ARPA
A loaded VAX-NIL MACSYMA has about 14 thousand of what you
call slink cells allocated, mostly for function cells. So if
you had implemented them as a slot in the symbol it would have
indeed been a loser. Actually, another thing the indirection
buys us is to make it possible to relocate symbols without putting
a lot of work into looking at compiled code or its support structures.
Another kind of function cell we see a lot of now is a
flavor-method-table entry. These also get a regular function
cell too now, for the purpose of "book-keeping" in the assembler/loader,
so the figure of 14 thousand is more than slightly bloated by this
and by procedures on property lists. The garbage collector can
clean up this garbage though if the loader did a MAKFUNBOUND.
As you pointed out, the multiple-namespace concept is a very useful
one, and one that programmers have to be able deal with.
People should know that real Scheme programmers can make use of the
multiple-namespace idea too. In Yale T or MIT "6.001 " scheme one
might do a few different things:
(putprop 'foo (lambda (...) ...) 'bar)
and then write
((get'foo'bar) ...)
or define something that looks cleaner and runs faster such as:
(define-namespace foo)
(define-in-namespace (foo bar) (lambda (...) ...))
and then write
((foo bar) ...)
The *hack* is that languages that are implemented efficiently enough
in *general* allow the user to add his own namespace concepts which will
run as fast as if the implementor had wired them into the system and
wrote about them in the manual himself.
I have observed that T, MIT SCHEME, VAX-NIL, and Lispmachine(s)
live up to this *hack*, requiring slightly different amounts of
kludgery on the part of the user in some cases, but with nothing at
the level of LAP or MICROCODE being required.
This puts the arguments on a totally different level, at least for
people with practical access to these kinds of languages/machines.
You can do an excelent implementation of maclisp namespacing in T,
and vice-versa (for the maclisp descendants such as lispm and nil).
On the other hand, architectural optimizations in hardware and/or
software can make it a real bitch (to use the techical term) to implement
tail-calling in some implementations.
-gjc
∂30-Sep-83 1202 @USC-ECL,@MIT-MC:GLR@MIT-OZ
Received: from USC-ECL by SU-AI with TCP/SMTP; 30 Sep 83 12:02:28 PDT
Received: from MIT-MC by USC-ECL; Fri 30 Sep 83 12:01:55-PDT
Date: Fri, 30 Sep 1983 14:38 EDT
Message-ID: <[MIT-OZ].GLR.30-Sep-83 14:38:42>
From: Jerry Roylance <GLR@MIT-OZ>
To: BUG-LISP@MIT-OZ
SETF (EVAL-ONCE) gets confused?
This works:
(setf (ldb ppss (arraycall fixnum array index)) val)
=> (store (arraycall fixnum array index)
(dpb val ppss (arraycall fixnum array index)))
But change val to a function call, and we start SETQ'ing gensyms
(setf (ldb ppss (arraycall fixnum array index)) (fcn))
=> (let ((g0001 (arraycall fixnum array index)))
(setq g0001
(dpb val ppss g0001)))